<div dir="ltr"><br><div class="gmail_extra"><br></div><div class="gmail_quote">On Wed, Jul 6, 2016 at 6:24 AM, Houssem Daoud <span dir="ltr"><<a href="mailto:houssem.daoud@polymtl.ca" target="_blank">houssem.daoud@polymtl.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">Hi,<br>
<br>
My system experiencing problems with atomic memory allocations. Device<br>
drivers are not able to allocate contiguous memory regions due to a high<br>
fragmentation level.<br>
<br>
At the time of failure: /proc/meminfo shows the following information:<br>
MemTotal: 4021820 Kb<br>
MemFree: 121912 Kb<br>
Active: 1304396 Kb<br>
Inactive: 2377124 Kb<br>
<br>
Most of the memory is consumed by the LRU inactive list and only 121 Mb<br>
is available to the system.<br>
By using a tracer, I found that most of the pages in the inactive list<br>
are created by the ext4 journal during a truncate operation.<br>
The call stack of the allocation is:<br>
[<br>
__alloc_pages_nodemask<br>
alloc_pages_current<br>
__page_cache_alloc<br>
find_or_create_page<br>
__getblk<br>
jbd2_journal_get_descriptor_buffer<br>
jbd2_journal_commit_transaction<br>
kjournald2<br>
kthread<br>
]<br>
<br>
The problem is easily reproducible using the following script:<br>
#!/bin/bash<br>
while true;<br>
do<br>
dd if=/dev/zero of=output.dat bs=100M count=1<br>
done<br>
<br>
Is that a normal behavior ? I know that the philosophy of memory<br>
management in Linux is to use the available memory as much as possible,<br>
but what is the need of keeping truncated pages in the LRU if we know<br>
that they are not even accessible ?<br>
<br>
The problem of the inactive list growth occurs only with the journal<br>
mode of ext4, not with the write-back mode.<br>
<br>
A chart representing the utilization of memory during the test is<br>
provided in this link:<br>
<a href="http://secretaire.dorsal.polymtl.ca/~hdaoud/ext4_journal_meminfo.png" target="_blank" rel="noreferrer">http://secretaire.dorsal.polymtl.ca/~hdaoud/ext4_journal_meminfo.png</a><br>
<br>
Thanks,<br>
Houssem<br>
<br>
<br>
_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
<a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank" rel="noreferrer">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
</blockquote></div><div class="gmail_extra"><br>Hi</div><div class="gmail_extra"><br></div><div class="gmail_extra">Trying to help here:</div><div class="gmail_extra">You said you wanna do atomic allocation. But then you said you want to allocate around ~100 MB contiguous memory region.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">But, for clarification, maybe you should also post your full content of /proc/buddyinfo and /proc/meminfo </div><div class="gmail_extra"><br clear="all"><br>-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature">regards,<br><br>Mulyadi Santosa<br>Freelance Linux trainer and consultant<br><br>blog: <a href="http://the-hydra.blogspot.com" target="_blank">the-hydra.blogspot.com</a><br>training: <a href="http://mulyaditraining.blogspot.com" target="_blank">mulyaditraining.blogspot.com</a></div><div class="gmail_extra">
</div></div>