Memory pages not released by the filesystem after a truncate
mulyadi.santosa at gmail.com
Wed Jul 6 12:29:55 EDT 2016
On Wed, Jul 6, 2016 at 6:24 AM, Houssem Daoud <houssem.daoud at polymtl.ca>
> My system experiencing problems with atomic memory allocations. Device
> drivers are not able to allocate contiguous memory regions due to a high
> fragmentation level.
> At the time of failure: /proc/meminfo shows the following information:
> MemTotal: 4021820 Kb
> MemFree: 121912 Kb
> Active: 1304396 Kb
> Inactive: 2377124 Kb
> Most of the memory is consumed by the LRU inactive list and only 121 Mb
> is available to the system.
> By using a tracer, I found that most of the pages in the inactive list
> are created by the ext4 journal during a truncate operation.
> The call stack of the allocation is:
> The problem is easily reproducible using the following script:
> while true;
> dd if=/dev/zero of=output.dat bs=100M count=1
> Is that a normal behavior ? I know that the philosophy of memory
> management in Linux is to use the available memory as much as possible,
> but what is the need of keeping truncated pages in the LRU if we know
> that they are not even accessible ?
> The problem of the inactive list growth occurs only with the journal
> mode of ext4, not with the write-back mode.
> A chart representing the utilization of memory during the test is
> provided in this link:
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
Trying to help here:
You said you wanna do atomic allocation. But then you said you want to
allocate around ~100 MB contiguous memory region.
IIRC, if you want to do atomic allocation, usually it can not be that big.
I am not sure how large, but surely not reaching 100 MB. For that size, I
think you should rely on vmalloc.
But, for clarification, maybe you should also post your full content of
/proc/buddyinfo and /proc/meminfo
Freelance Linux trainer and consultant
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Kernelnewbies