On Thu, Apr 03, 2008 at 08:40:41PM -0700, Nish Aravamudan wrote:

quoted text
> Hrm, fio is using SHM_HUGETLB. Does ipcs indicate maybe fio is not
> cleaning up the shared memory segment? FWIW, it seems like each run is
> using 400 hugepages in the SHM_HUGETLB segment, and then when you try
> to force the pool to shrink, it converts those 800 (since you ran fio
> twice) hugepages from static pool pages to dynamic (or overcommit)
> pages.
> 
> On another note, it is odd that we're using the dynamic pool, when it
> is initially disabled...I'll have to think about that.
> 
> I'll try and look at this later this evening or early tomorrow.

Yes that is an expected result.  We have no way to force the pool to
shrink when pages are in-use.  When a request is made to redoce the pool
below the number of in-use pages, we move the pages to surplus.  While
this does temporarily violate the overcommit cap, it does provide the
most utility as those pages will be returned to the buddy at the
earliest oppotunity.

I suspect the documenation could do with a little clarification.

-apw
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/