Re: mallinfo(3) man page for review

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(5/5/12 5:50 PM), Michael Kerrisk (man-pages) wrote:
Motohiro,

Thank you for taking the time to look at this.

On Sun, May 6, 2012 at 9:25 AM, KOSAKI Motohiro
<kosaki.motohiro@xxxxxxxxx>  wrote:
Hi

On Fri, May 4, 2012 at 8:08 PM, Michael Kerrisk (man-pages)
<mtk.manpages@xxxxxxxxx>  wrote:
I've written the man page page below to document glibc's mallinfo(3).
Review comments welcome!

Cheers,

Michael

I don't find any issue. a few nit are below.


.TP 10
.I arena
The total amount of memory allocated by means other than
.BR mmap (2)
(i.e., memory allocated on the heap).
This figure includes both in-use blocks and blocks on the free list.
.TP
.I ordblks
The number of ordinary (i.e., non-fastbin) free blocks.
.TP
.I smblks
The number of fastbin free blocks (see
.BR mallopt (3)).

It would be nice if a meaning of fastbin was described here.
It is allocation cache (for increasing cpu cache hit ratio) from
point of bird view.

In the new mallopt(3) that is part of the next man-pages release,
there is this text on fastbins:

        M_MXFAST (since glibc 2.3)
               Set the upper limit for memory allocation requests  that
               are  satisfied  using "fastbins".  (The measurement unit
               for this parameter  is  bytes.)   Fastbins  are  storage
               areas that hold deallocated blocks of memory of the same
               size without merging adjacent free  blocks.   Subsequent
               reallocation  of  blocks of the same size can be handled
               very quickly by allocating from  the  fastbin,  although
               memory fragmentation and the overall memory footprint of
               the program can increase.  The default  value  for  this
               parameter  is  64*sizeof(size_t)/4  (i.e.,  64 on 32-bit
               architectures).  The range for this parameter  is  0  to
               80*sizeof(size_t)/4.  Setting M_MXFAST to 0 disables the
               use of fastbins.

Probably this is sufficient?

Yes, very good. can you please refer mallopt here?


.TP
.I hblks
The number of blocks currently allocated using
.BR mmap (2).

It would be nice if glibc malloc try to allocate memory by using mmap directly
if size is greater than MMAP_THRESHOLD.

Also nice if refer mallopt and MMAP_THRESHOLD.

Good idea. I added:

[[
(See the discussion of
.B M_MMAP_THRESHOLD
in
.BR mallopt (3).)
]]

In the new mallopt(3) page, there is then this text:

        M_MMAP_THRESHOLD
               For allocations greater than or equal to the limit spec‐
               ified  (in bytes) by M_MMAP_THRESHOLD that can't be sat‐
               isfied from the free list, the  memory-allocation  func‐
               tions  employ  mmap(2) instead of increasing the program
               break using sbrk(2).

               Allocating memory  using  mmap(2)  has  the  significant
               advantage that the allocated memory blocks can always be
               independently released back to  the  system.   (By  con‐
               trast,  the  heap can be trimmed only if memory is freed
               at the top end.)  On the other hand, there are some dis‐
               advantages  to  the use of mmap(2): deallocated space is
               not placed on the free list for reuse by  later  alloca‐
               tions;  memory may be wasted because mmap(2) allocations
               must be page-aligned; and the kernel  must  perform  the
               expensive  task  of  zeroing  out  memory  allocated via
               mmap(2).  Balancing these factors  leads  to  a  default
               setting of 128*1024 for the M_MMAP_THRESHOLD parameter.

               The  lower  limit  for  this  parameter is 0.  The upper
               limit is DEFAULT_MMAP_THRESHOLD_MAX: 512*1024 on  32-bit
               systems or 4*1024*1024*sizeof(long) on 64-bit systems.

               Note:  Nowadays,  glibc uses a dynamic mmap threshold by
               default.   The  initial  value  of  the   threshold   is
               128*1024,  but  when  blocks  larger  than  the  current
               threshold and less than or equal to DEFAULT_MMAP_THRESH‐
               OLD_MAX  are freed, the threshold is adjusted upwards to
               the size of the freed block.  When dynamic mmap  thresh‐
               olding is in effect, the threshold for trimming the heap
               is also dynamically adjusted to  be  twice  the  dynamic
               mmap  threshold.  Dynamic adjustment of the mmap thresh‐
               old  is  disabled  if  any  of   the   M_TRIM_THRESHOLD,
               M_TOP_PAD, M_MMAP_THRESHOLD, or M_MMAP_MAX parameters is
               set.

very nice!

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux