brk()系统调用完成了数据段大小改变的功能，当然包括增加(malloc,申请)和减小(free,释放)两部分了。

    这一系统调用在一般应用中不会出现，但是可以确定一定是被使用最多的，因为其被malloc()调用，malloc()库函数的操作后续给出，但据说，是lib库为应用程序提供了内存管理的方法，当其管理的内存不足的时候，库向内核批量申请一段内存，当然要满足页面对齐的条件，即所分配的空间应该为页面大小的整数倍。

    在查看进程的内存使用情况时，我们也可以通过top得到VSZ的值，也可以使用如下命令得到进程的其他参数：

root@catalyst_24FD52F24E00:/tmp/log# cat /proc/`pidof snmpd`/status

Name:   snmpd

State:  S (sleeping)

Tgid:   4258

Pid:    4258

PPid:   1

TracerPid:      0

Uid:    0       0       0       0

Gid:    0       0       0       0

FDSize: 32

Groups:

VmPeak:     3748 kB

VmSize:     3748 kB

VmLck:         0 kB

VmHWM:      1308 kB

VmRSS:      1308 kB

VmData:      968 kB

VmStk:       136 kB

VmExe:       716 kB

VmLib:      1768 kB

VmPTE:        16 kB

VmSwap:        0 kB

Threads:        1

SigQ:   0/475

SigPnd: 00000000000000000000000000000000

ShdPnd: 00000000000000000000000000000000

SigBlk: 00000000000000000000000000000000

SigIgn: 00000000000000000000000000001004

SigCgt: 0000000000000000000000004000c003

CapInh: 0000000000000000

CapPrm: ffffffffffffffff

CapEff: ffffffffffffffff

CapBnd: ffffffffffffffff

Cpus_allowed:   1

Cpus_allowed_list:      0

voluntary_ctxt_switches:        32233

nonvoluntary_ctxt_switches:     12093

root@catalyst_24FD52F24E00:/tmp/log# 

    其中的VmPeak反应的是该程序所使用所有内存的大小，在内核中，通过mm->total_vm反映出来：

[fs/proc/task_mmu.c: task_mem()]

void task_mem(struct seq_file *m, struct mm_struct *mm)

{

unsigned long data, text, lib, swap;

unsigned long hiwater_vm, total_vm, hiwater_rss, total_rss;


/*

* Note: to minimize their overhead, mm maintains hiwater_vm and

* hiwater_rss only when about to *lower* total_vm or rss.  Any

* collector of these hiwater stats must therefore get total_vm

* and rss too, which will usually be the higher.  Barriers? not

* worth the effort, such snapshots can always be inconsistent.

*/

hiwater_vm = total_vm = mm->total_vm;

...

seq_printf(m,

"VmPeak:\t%8lu kB\n"

"VmSize:\t%8lu kB\n"

"VmLck:\t%8lu kB\n"

"VmHWM:\t%8lu kB\n"

"VmRSS:\t%8lu kB\n"

"VmData:\t%8lu kB\n"

"VmStk:\t%8lu kB\n"

"VmExe:\t%8lu kB\n"

"VmLib:\t%8lu kB\n"

"VmPTE:\t%8lu kB\n"

"VmSwap:\t%8lu kB\n",

hiwater_vm << (PAGE_SHIFT-10),

...

}

    该函数主要是在进程任务的proc下生成对应的status统计信息。

    要想明确获知VmPeak的来源，当然离不开malloc()库函数了，而这一函数将会调用brk()系统调用，下面，开始吧。


    brk()系统调用的部分过程如下：

[mm/mmap.c: brk()]

SYSCALL_DEFINE1(brk, unsigned long, brk)

{

...

/* Ok, looks good - let it rip. */

if (do_brk(oldbrk, newbrk-oldbrk) != oldbrk)

goto out;


set_brk:

mm->brk = brk;

out:

retval = mm->brk;

up_write(&mm->mmap_sem);

return retval;

}

    由上面的调用过程不难发现，brk()主要通过do_brk()完成其主要的功能。

    do_brk()的部分代码如下：

[mm/mmap.c: brk()->do_brk()]

/*

 *  this is really a simplified "do_mmap".  it only handles

 *  anonymous maps.  eventually we may be able to do some

 *  brk-specific accounting here.

 */

unsigned long do_brk(unsigned long addr, unsigned long len)

{

...

/*

* Clear old maps.  this also does some error checking for us

*/

 munmap_back:

vma = find_vma_prepare(mm, addr, &prev, &rb_link, &rb_parent);

if (vma && vma->vm_start < addr + len) {

if (do_munmap(mm, addr, len))

return -ENOMEM;

goto munmap_back;

}


/* Check against address space limits *after* clearing old maps... */

if (!may_expand_vm(mm, len >> PAGE_SHIFT))

return -ENOMEM;


if (mm->map_count > sysctl_max_map_count)

return -ENOMEM;


if (security_vm_enough_memory(len >> PAGE_SHIFT))

return -ENOMEM;


/* Can we just expand an old private anonymous mapping? */

vma = vma_merge(mm, prev, addr, addr + len, flags,

NULL, NULL, pgoff, NULL);

if (vma)

goto out;


/*

* create a vma struct for an anonymous mapping

*/

vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);

if (!vma) {

vm_unacct_memory(len >> PAGE_SHIFT);

return -ENOMEM;

}

INIT_LIST_HEAD(&vma->anon_vma_chain);

vma->vm_mm = mm;

vma->vm_start = addr;

vma->vm_end = addr + len;

vma->vm_pgoff = pgoff;

vma->vm_flags = flags;

vma->vm_page_prot = vm_get_page_prot(flags);

vma_link(mm, vma, prev, rb_link, rb_parent);

out:

perf_event_mmap(vma);

mm->total_vm += len >> PAGE_SHIFT;

if (flags & VM_LOCKED) {

if (!mlock_vma_pages_range(vma, addr, addr + len))

mm->locked_vm += (len >> PAGE_SHIFT);

}

return addr;

}

    上面的代码完成了释放、内存申请、内存空间映射关系建立等功能，后续对这些部分进行分解。

    此时关注于另一点：mm中的total_vm成员。

    由上面的代码中发现，total_vm在最后会增加此次调整的长度，而且其单位页面大小，在这里2.6.36为4KB。

    下面一点没有进行对应的验证：由上面的计算来看，应该是在free的时候，total_vm的值会变小才对，因为此时len为负值，所以total_vm应该降低；但是前文说过，lib库为应用程序提供了一个内存管理的方法，只有在其内存不足的时候，才向内核申请内存，然后返回给应用程序其所期望的空间大小，如此，则lib库并不会将应用程序free的内存释放到系统的剩余内存中，所以将会导致total_vm会存在持续增长的情况。那么，此时就存在一个问题了，是lib库导致了total_vm的增长么？total_vm的真正作用是什么？在什么时候，total_vm会降低？为什么有些系统中，