dirty页 linux_linux nr_dirty 脏页 - CSDN
  • 驱动需要对应内核版本号,但是有的内核版本号带有dirty后缀,这是编译内核的时候自动添加的。 只要编译内核时,去掉自动添加版本的选项即可。 General setup ---> [ ] Automatically append version ...

    驱动需要对应内核版本号,但是有的内核版本号带有dirty后缀,这是编译内核的时候自动添加的。

    只要编译内核时,去掉自动添加版本的选项即可。

    General setup  --->
    [ ] Automatically append version information to the version string

    展开全文
  • http://feichashao.com/dirty_ratio_and_dirty_background_ratio/ 最近产品在个别用户环境下经常发生hang住的行为,通过atop的纪录发现在系统中有持续的内存swap转换,高IO的现象。推测和这两个参数有关,准备...

    http://feichashao.com/dirty_ratio_and_dirty_background_ratio/


    最近产品在个别用户环境下经常发生hang住的行为,通过atop的纪录发现在系统中有持续的内存swap转换,高IO的现象。推测和这两个参数有关,准备进行进一步的实验。


    但是cache和free 和swap却均保持一个比较平稳的状态,所以有可能是这个参数的不合适导致经常的IO读写。

    展开全文
  • Linux页框管理

    2010-01-23 11:59:00
    在前面的博文里,我们讲解了基于80x86体系的Linux内核分段和分页机制,并详细地讨论了Linux的内存布局。有了这些基本概念以后,我们就来详细讨论内核如何动态地管理那些可用的内存空间。 对于80386这种32位的处理器...

    在前面的博文里,我们讲解了基于80x86体系的Linux内核分段和分页机制,并详细地讨论了Linux的内存布局。有了这些基本概念以后,我们就来详细讨论内核如何动态地管理那些可用的内存空间。

     

    对于80386这种32位的处理器结构,Linux采用4KB页框大小作为标准的内存分配单元。内核必须记录每个页框的当前状态,例如,区分哪些页框包含的是属于进程的页,而哪些页框包含的是内核代码或内核数据。内核还必须能够确定动态内存中的页框是否空闲,如果动态内存中的页框不包含有用的数据,那么这个页框就是空闲的。在以下情况下页框是不空闲的:包含用户态进程的数据、某个软件高速缓存的数据、动态分配的内核数据结构、设备驱动程序缓冲的数据、内核模块的代码等等。

     

    内核用数据结构page描述一个页框的状态信息,所有的页描述符存放在全局mem_map数组中,其数组的下标为页框号(pfn)。因为每个描述符长度为32字节,所以mem_map所需要的空间略小于整个RAM的1%。

     

    那么一个页描述符怎样与一个占据4k的页框相联系(映射)呢?有了mem_map数组,这个问题就很简单了。因为如果知道了page数据的地址pd,用pd去减去mem_map就得到了pd的页框号pfn。那么这个物理页的物理地址是physAddr = pfn << PAGE_SHIFT  。


    在得知该物理页的物理地址是physAddr后,就可以视physAddr的大小得到它的虚拟地址:
    1.physAddr < 896M  对应虚拟地址是 physAddr + PAGE_OFFSET   (PAGE_OFFSET=3G)
    2.physAddr >= 896M 对应虚拟地址不是静态映射的,通过内核的高端虚拟地址映射得到一个虚拟地址。

     

    在得到该页的虚拟地址之后,内核就可以正常访问这个物理页了。

     

    内核提供一个virt_to_page(addr)宏来产生线性地址addr对应的页描述符地址。pfn_to_page(pfn)宏产生与页框号pfn对应的页描述符地址。相反,也提供page_to_pfn(pg)宏来产生页描述符对应的页的页框号pfn。注意,针对80x86结构,上述宏并不是直接通过men_map数组来确定页框号的,而是通过内存管理区的zone_mem_map来确定的,不过原理是一样的:

    #define page_to_pfn(pg)       /
    ({         /
     struct page *__page = pg;     /
     struct zone *__zone = page_zone(__page);   /
     (unsigned long)(__page - __zone->zone_mem_map)   /
      + __zone->zone_start_pfn;    /
    })

     

    这里千万要注意!不要混淆一个概念。这里的physAddr虽然表示物理地址,但是并不能说明该地址的数据就一定存在于物理内存中。那么如何判断这个页到底在不在内存中呢?你看,前面的知识就用到了——分页机制。也就是说,如果这个页因为各种各样五花八门的原因被交换出去了,那么它对应的页的Present标志就为0。这里就牵涉到缺页异常了,要深入了解,请关注笔者后面的博文。

     

    在这里我们只需要对数据结构page详细讨论以下两个字段:
    1、_count:页的引用计数器。如果该字段为-1,则相应页框空闲,并可被分配给任一进程或内核本身;如果该字段的值大于或等于0,则说明页框被分配给一个或多个进程,或用于存放一些内核数据结构。page_count()函数返回_count加1后的值,也就是该页的使用者的数目。
    2、flags:包含多达32个用来描述页框状态的标志。对于每个PG_xyz标志,内核都定义了操纵其值的一些宏。通常,PageXyz宏返回标志的值,而SetPageXyz和ClearPageXyz宏分别设置和清除相应的位。

     

    标志名

    含义

    PG_locked

    页被锁定,例如,在磁盘I/O操作中涉及的页。

    PG_error

    在传输页时发生错误

    PG_referenced

    刚刚访问过的页

    PG_uptodate

    在完成读操作后置位,除非发生磁盘I/O 错误

    PG_dirty

    页已经被修改

    PG_lru

    页在活动或非活动页链表中

    PG_active

    页在活动页链表中

    PG_slab

    包含在slab 中的页框

    PG_highmem

    页框属于ZONE_HIGHMEM 管理区

    PG_checked

    由一些文件系统(如Ext2 Ext3)使用的标志

    PG_arch_1

    80x86 体系结构上没有使用

    PG_reserved

    页框留给内核代码或没有使用

    PG_private

    页描述符的private字段存放了有意义的数据

    PG_writeback

    正在使用writepage方法将页写到磁盘上

    PG_nosave

    系统挂起 / 唤醒时使用

    PG_compound

    通过扩展分页机制处理页框

    PG_swapcache

    页属于对换高速缓存

    PG_mappedtodisk

    页框中的所有数据对应于磁盘上分配的块

    PG_reclaim

    为回收内存对页已经做了写入磁盘的标记

    PG_nosave_free

    系统挂起 / 恢复时使用

     

    系统是怎么为进程或内核分配一个内存空间,或者说怎么给他们分配一个线性页描述符所对应线性地址的页面呢?这个需要借助内核的分区页框分配器和伙伴系统算法。在讨论这些细节之前,先介绍一些必要的概念。

     

    1 非统一内存访问(NUMA)架构

     

    Linux2.6支持非统一内存访问(NUMA)模型,在这种模型中,给定CPU对不同内存单元的访问时间可能不一样。系统的物理内存被划分为几个节点(node)。在一个单独的节点内,任一给定CPU访问页面所需要的时间都是相同的,而对于不同的CPU,这个时间就不同。对每个CPU而言,内核都试图把耗时节点的访问次数减到最少,这就必须要将那些CPU最常引用的内核数据结构的存放位置选好。

     

    每个节点由一个类型为pg_data_t的描述符表示,所有节点的描述符存放在一个单向链表中,它的第一个元素由内核全局变量pgdat_list指向。在x86体系中,即使是多核,内存访问时间也是相同的,所以不需要NUMA,但是内核还是使用节点,不过,这只是一个单独的节点,它包含了系统中所有的物理内存。因此,pgdat_list变量指向一个链表,此链表只有一个元素组成的,这个元素就是节点0描述符,它被存放在contig_page_data变量中。

     

    pg_data_t描述符中要注意到的三个字段分别是node_zones、node_zonelists、node_mem_map,分别是zone_t[]、zonelist_t[]和page类型。前两个是用来描述内存管理区的,下面马上要谈到;node_mem_map是本节点所有页的页描述符数组。内核将这三个字段放在里边,就是为内存区、页框建立一些列的联系。

     

    2 内存管理区

     

    由于Linux内核必须处理80x86体系结构中的两种硬件约束:
    (1)ISA总线的直接内存存取(DMA)处理器有一个严格的限制:他们只能对RAM的前16MB寻址。
    (2)在具有较大容量RAM的现代32位计算机中,CPU不能直接访问所有的物理内存,因为线性地址空间太小。

     

    为了应对这两种限制,Linux2.6把每个内存节点的物理内存划分成3个管理区(zone)。在80x86的UMA体系结构中的管理区分为:
    ZONE_DMA:包含低于16MB的内存页框
    ZONE_NORMAL:包含高于16MB而低于896MB的内存页框
    ZONE_HIGHMEM:包含从896MB开始高于896MB的内存页框

     

    ZONE_DMA和ZONE_NORMAL区包含内存“常规”页框,通过把他们线性地址映射到线性地址空间的第4个GB,内核就可以直接进行访问。ZONE_HIGHMEM区包含的内存页不能由内核直接访问,尽管它们也可以通过高端内存内核映射,线性映射到线性地址空间的第4个GB。

     

    每个内存管理区都有自己的描述符zone_t,其字段中很多用于回收页框时使用。其实每个页描述符page都有到内存节点和到内存节点管理区的链接。那我们为啥看不到呢,原因是为了节省空间,这些链接的存放方式和典型的指针不同,是被编码成索引存放在flags字段的高位。

     

     zone_t字段如下:

    类型

    名称

    说明

    unsigned long

    free_pages

    管理区中空闲页的数量

    unsigned long

    pages_min

    管理区中保留页的数目

    unsigned long

    pages_low

    回收页框使用的下界;同时也被管理区分配器作为阈值使用

    unsigned long

    pages_high

    回收页框使用的上界;同时也被管理区分配器作为阈值使用

    unsigned long []

    lowmem_reserve

    指明在处理内存不足的临界情况下每个管理区必须保留的页框数目

    struct per_cpu_pageset[]

    pageset

    数据结构用于实现单一页框的特殊高速缓存

    spinlock_t

    lock

    保护该描述符的自旋锁

    struct free_area []

    free_area

    标识出管理区中的空闲页框块

    spinlock_t

    lru_lock

    活动以及非活动链表使用的自旋锁

    struct list head

    active_list

    管理区中的活动页链表

    struct list head

    inactive_list

    管理区中的非活动页链表

    unsigned long

    nr_scan_active

    回收内存时需要扫描的活动页数目

    unsigned long

    nr_scan_inactive

    回收内存时需要扫描的非活动页数目

    unsigned long

    nr_active

    管理区的活动链表上的页数目

    unsigned long

    nr_inactive

    管理区的非活动链表上的页数目

    unsigned long

    pages_scanned

    管理区内回收页框时使用的计数器

    int

    all_unreclaimable

    在管理区中填满不可回收页时此标志被置位

    int

    temp_priority

    临时管理区的优先级(回收页框时使用)

    int

    prev_priority

    管理区优先级,范围在12 0 之间(由回收页框算法使用)

    wait_queue_head_t *

    wait_table

    进程等待队列的散列表,这些进程正在等待管理区中的某页

    unsigned long

    wait_table_size

    等待队列散列表的大小

    unsigned long

    wait_table_bits

    等待队列散列表数组大小,值为2order

    struct pglist_data *

    zone_pgdat

    内存节点

    struct page *

    zone_mem_map

    指向管理区的第一个页描述符的指针

    unsigned long

    zone_start_pfn

    管理区第一个页框的下标

    unsigned long

    spanned_pages

    以页为单位的管理区的总大小,包括洞

    unsigned long

    present_pages

    以页为单位的管理区的总大小,不包括洞

    char *

    name

    指针指向管理区的传统名称:“DMA”,“NORMAL”或“HighMem

     

    实际上,刻画页框的标志的数目是有限的,因此保留flags字段的最高位来编码内存节点和管理区是绰绰有余的。Linux提供page_zone()函数用来接收一个页描述符的地址作为它的参数;它读取该描述符中的flags字段的最高位,然后通过查看zone_table数组来确定相应管理区描述符的地址。顺便提一下,在系统启动时用,内核将所有内存节点的所有管理区描述符的地址放到这个zone_table数组里边。

     

    当内核调用一个内存分配函数时,必须指明请求页框所在的管理区。内核通常指明它愿意使用哪个管理区。为了在内存分配请求中指定首选管理区,内核使用zonelist数据结构,这就是管理区描述符指针数组,在80x86中只有三个zone,所以zonelist数据结构中指向这三个zone的指针按照一定规则排列。如图,则zonelist数组就是这三个zone的排列组合。

    管理区

    例如,要分配一个用来做DMA的页框,则在指定zonelist数组中的某个zonelist元素中获得首选的zone,应该是ZONE_DMA,如果该区空间已使用完,就选ZONE_NORMA区,随后再是ZONE_HIGHMEM。

    展开全文
  • 文件系统缓存dirty_ratio与dirty_background_ratio两个参数区别 (2014-03-16 17:54:32) 转载▼ 标签: linux 文件系统缓存 cache dirty_ratio dirty_background_rat it 分类: 专业学习 ...

    文件系统缓存dirty_ratio与dirty_background_ratio两个参数区别

    (2014-03-16 17:54:32)

          这两天在调优数据库性能的过程中需要降低操作系统文件Cache对数据库性能的影响,故调研了一些降低文件系统缓存大小的方法,其中一种是通过修改/proc/sys/vm/dirty_background_ration以及/proc/sys/vm/dirty_ratio两个参数的大小来实现。看了不少相关博文的介绍,不过一直弄不清楚这两个参数的区别在哪里,后来看了下面的一篇英文博客才大致了解了它们的不同。

    vm.dirty_background_ratio:这个参数指定了当文件系统缓存脏页数量达到系统内存百分之多少时(如5%)就会触发pdflush/flush/kdmflush等后台回写进程运行,将一定缓存的脏页异步地刷入外存;
     
    vm.dirty_ratio:而这个参数则指定了当文件系统缓存脏页数量达到系统内存百分之多少时(如10%),系统不得不开始处理缓存脏页(因为此时脏页数量已经比较多,为了避免数据丢失需要将一定脏页刷入外存);在此过程中很多应用进程可能会因为系统转而处理文件IO而阻塞。
     
    之前一直错误的一位dirty_ratio的触发条件不可能达到,因为每次肯定会先达到vm.dirty_background_ratio的条件,后来才知道自己理解错了。确实是先达到vm.dirty_background_ratio的条件然后触发flush进程进行异步的回写操作,但是这一过程中应用进程仍然可以进行写操作,如果多个应用进程写入的量大于flush进程刷出的量那自然会达到vm.dirty_ratio这个参数所设定的坎,此时操作系统会转入同步地处理脏页的过程,阻塞应用进程。
     

    附上原文:

    Better Linux Disk Caching & Performance with vm.dirty_ratio & vm.dirty_background_ratio

    by BOB PLANKERS on DECEMBER 22, 2013

    in BEST PRACTICES,CLOUD,SYSTEM ADMINISTRATION,VIRTUALIZATION

     

    This is post #16 in my December 2013 series about Linux Virtual Machine Performance Tuning. For more, please see the tag “Linux VM Performance Tuning.”

    In previous posts on vm.swappiness and using RAM disks we talked about how the memory on a Linux guest is used for the OS itself (the kernel, buffers, etc.), applications, and also for file cache. File caching is an important performance improvement, and read caching is a clear win in most cases, balanced against applications using the RAM directly. Write caching is trickier. The Linux kernel stages disk writes into cache, and over time asynchronously flushes them to disk. This has a nice effect of speeding disk I/O but it is risky. When data isn’t written to disk there is an increased chance of losing it.

    There is also the chance that a lot of I/O will overwhelm the cache, too. Ever written a lot of data to disk all at once, and seen large pauses on the system while it tries to deal with all that data? Those pauses are a result of the cache deciding that there’s too much data to be written asynchronously (as a non-blocking background operation, letting the application process continue), and switches to writing synchronously (blocking and making the process wait until the I/O is committed to disk). Of course, a filesystem also has to preserve write order, so when it starts writing synchronously it first has to destage the cache. Hence the long pause.

    The nice thing is that these are controllable options, and based on your workloads & data you can decide how you want to set them up. Let’s take a look:

    $ sysctl -a | grep dirty
     vm.dirty_background_ratio = 10
     vm.dirty_background_bytes = 0
     vm.dirty_ratio = 20
     vm.dirty_bytes = 0
     vm.dirty_writeback_centisecs = 500
     vm.dirty_expire_centisecs = 3000
    

    vm.dirty_background_ratio is the percentage of system memory that can be filled with “dirty” pages — memory pages that still need to be written to disk — before the pdflush/flush/kdmflush background processes kick in to write it to disk. My example is 10%, so if my virtual server has 32 GB of memory that’s 3.2 GB of data that can be sitting in RAM before something is done.

    vm.dirty_ratio is the absolute maximum amount of system memory that can be filled with dirty pages before everything must get committed to disk. When the system gets to this point all new I/O blocks until dirty pages have been written to disk. This is often the source of long I/O pauses, but is a safeguard against too much data being cached unsafely in memory.

    vm.dirty_background_bytes and vm.dirty_bytes are another way to specify these parameters. If you set the _bytes version the _ratio version will become 0, and vice-versa.

    vm.dirty_expire_centisecs is how long something can be in cache before it needs to be written. In this case it’s 30 seconds. When the pdflush/flush/kdmflush processes kick in they will check to see how old a dirty page is, and if it’s older than this value it’ll be written asynchronously to disk. Since holding a dirty page in memory is unsafe this is also a safeguard against data loss.

    vm.dirty_writeback_centisecs is how often the pdflush/flush/kdmflush processes wake up and check to see if work needs to be done.

    You can also see statistics on the page cache in /proc/vmstat:

    $ cat /proc/vmstat | egrep "dirty|writeback"
     nr_dirty 878
     nr_writeback 0
     nr_writeback_temp 0
    

    In my case I have 878 dirty pages waiting to be written to disk.

    Approach 1: Decreasing the Cache

    As with most things in the computer world, how you adjust these depends on what you’re trying to do. In many cases we have fast disk subsystems with their own big, battery-backed NVRAM caches, so keeping things in the OS page cache is risky. Let’s try to send I/O to the array in a more timely fashion and reduce the chance our local OS will, to borrow a phrase from the service industry, be “in the weeds.” To do this we lower vm.dirty_background_ratio and vm.dirty_ratio by adding new numbers to /etc/sysctl.conf and reloading with “sysctl –p”:

    vm.dirty_background_ratio = 5
    vm.dirty_ratio = 10
    

    This is a typical approach on virtual machines, as well as Linux-based hypervisors. I wouldn’t suggest setting these parameters to zero, as some background I/O is nice to decouple application performance from short periods of higher latency on your disk array & SAN (“spikes”).

    Approach 2: Increasing the Cache

    There are scenarios where raising the cache dramatically has positive effects on performance. These situations are where the data contained on a Linux guest isn’t critical and can be lost, and usually where an application is writing to the same files repeatedly or in repeatable bursts. In theory, by allowing more dirty pages to exist in memory you’ll rewrite the same blocks over and over in cache, and just need to do one write every so often to the actual disk. To do this we raise the parameters:

    vm.dirty_background_ratio = 50
    vm.dirty_ratio = 80
    

    Sometimes folks also increase the vm.dirty_expire_centisecs parameter to allow more time in cache. Beyond the increased risk of data loss, you also run the risk of long I/O pauses if that cache gets full and needs to destage, because on large VMs there will be a lot of data in cache.

    Approach 3: Both Ways

    There are also scenarios where a system has to deal with infrequent, bursty traffic to slow disk (batch jobs at the top of the hour, midnight, writing to an SD card on a Raspberry Pi, etc.). In that case an approach might be to allow all that write I/O to be deposited in the cache so that the background flush operations can deal with it asynchronously over time:

    vm.dirty_background_ratio = 5
    vm.dirty_ratio = 80
    

    Here the background processes will start writing right away when it hits that 5% ceiling but the system won’t force synchronous I/O until it gets to 80% full. From there you just size your system RAM and vm.dirty_ratio to be able to consume all the written data. Again, there are tradeoffs with data consistency on disk, which translates into risk to data. Buy a UPS and make sure you can destage cache before the UPS runs out of power. :)

    No matter the route you choose you should always be gathering hard data to support your changes and help you determine if you are improving things or making them worse. In this case you can get data from many different places, including the application itself, /proc/vmstat, /proc/meminfo, iostat, vmstat, and many of the things in /proc/sys/vm. Good luck!

     

    转载自:

    http://blog.sina.com.cn/s/blog_448574810101k1va.html

    转载于:https://www.cnblogs.com/xibuhaohao/p/11096115.html

    展开全文
  • Linux内核中的概念,因为硬盘的读写速度远赶不上内存的速度,系统就把读写比较频繁的数据事先放到内存中,以提高读写速度,这就叫高速缓存,linux是以作为高速缓存的单位,当进程修改了高速缓存里的数据时,...
  • 关于“Dirty COW" 的影响,这方面的文章网上写的太多了,但是关于此漏洞真实成因的文章却很缺乏,基于此,我写了这篇文章,希望对想深入研究的人一些帮助。脏牛漏洞核心成因: 基于下面的POC来讲,要篡改的...
  • linux查看脏页数

    2017-09-28 19:50:41
    cat /proc/vmstat | egrep 'dirty|writeback' 输出的:nr_dirty 就代表多少脏
  • ARM Linux 如何模拟X86 PTE中的Present Young和Dirty标志位 原创文章,转载请注明出处.转载自:Li Haifeng's Blog 本文链接地址:ARM Linux 如何模拟X86 PTE中的Present Young和Dirty标志位 注:本文是参考Kernel的...
  • 原文地址:http://blog.csdn.NET/adaptiver/article/details/7225980 转载说明:你可能想不到,是Git管理的“问题”,看下面的解析,对于u-boot也是有同样的效果。 问题解决方案: ... 1.... 2....
  • 在系统的初始化阶段,内核根据检测到的物理内存的大小,为每一个页面都建立一个page结构,形成一个page结构的数组,并使一个全局量mem_map指向这个数组。 又按需要将这些页面拼合成物理地址连续的许多内存页面...
  • Linux dirty page回写时机

    2012-03-15 17:34:15
    1 定时方式: 定时回写是基于这样的原则:/proc/sys/vm/dirty_writeback_centisecs的值表示多长时间会启动回写线程,由这个定时器启动的回写...100)秒的(这个值默认是3000,也就是30秒),一般情况下dirty_writeback_centis
  • 有时在linux中的文件浏览器(例如nautilus,下面用此举例)中复制或者移动文件,会发现进度条很快就完成了,显示剩余0s,但是却迟迟不显示操作成功。 原因是当nautilus在处理写入操作时,linux内核把排队等待写入...
  • Linux内核将磁盘写入缓存,并随着时间的推移异步将它们刷新到磁盘。这对加速磁盘I / O有很好的效果,但风险很大。当数据未写入磁盘时,丢失数据的可能性会增加。 也有很多I / O也有可能压倒缓存。曾经一次将大量数据...
  • [原文] http://www.phpfans.net/article/htmls/201010/MzEwNzAx.html 延伸阅读: cgroup限制用户IOPS,共用文件系统,引发的思考: ... 系统缓存相关
  • 虽然仔细看过《linux内核设计与实现》,也参考了很多的博客,并且做了linux进程空间、address_space和文件的关系图(设为图1,参考博客),但是对于缓存和文件IO之间关系的细节一直不是特别明朗。趁着元旦假期看的...
  • linux页框分配与释放

    2017-10-29 14:58:14
    目录 1. 的分配 2 1.1 Alloc fast path 2 1.1.1从选定内存域分配 3 1.1.2 Alloc Fallbacks 5 1.1.3联合 8 1.2 Alloc slowpath 8 2. 的释放 10 3. 伙伴系统 11
1 2 3 4 5 ... 20
收藏数 22,038
精华内容 8,815
关键字:

dirty页 linux