kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: houssem.daoud@polymtl.ca (Houssem Daoud)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Memory pages not released by the filesystem after a truncate
Date: Tue, 5 Jul 2016 19:24:12 -0400	[thread overview]
Message-ID: <e484dc49-d8ea-765c-6a2b-0cecb993c579@polymtl.ca> (raw)

Hi,

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:
[
__alloc_pages_nodemask
alloc_pages_current
__page_cache_alloc
find_or_create_page
__getblk
jbd2_journal_get_descriptor_buffer
jbd2_journal_commit_transaction
kjournald2
kthread
]

The problem is easily reproducible using the following script:
#!/bin/bash
while true;
do
dd if=/dev/zero of=output.dat  bs=100M count=1
done

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: 
http://secretaire.dorsal.polymtl.ca/~hdaoud/ext4_journal_meminfo.png

Thanks,
Houssem

             reply	other threads:[~2016-07-05 23:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-05 23:24 Houssem Daoud [this message]
2016-07-06 16:29 ` Memory pages not released by the filesystem after a truncate Mulyadi Santosa
2016-07-12 21:12   ` Houssem Daoud
2016-07-12 21:16   ` Houssem Daoud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e484dc49-d8ea-765c-6a2b-0cecb993c579@polymtl.ca \
    --to=houssem.daoud@polymtl.ca \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).