linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nikolay Borisov <kernel@kyup.com>
To: Linux MM <linux-mm@kvack.org>
Cc: vbabka@suse.cz, mgorman@techsingularity.net
Subject: memory fragmentation issues on 4.4
Date: Mon, 28 Mar 2016 12:14:02 +0300	[thread overview]
Message-ID: <56F8F5DA.6040206@kyup.com> (raw)

Hello,

On kernel 4.4 I observe that the memory gets really fragmented fairly
quickly. E.g. there are no order  > 4 pages even after 2 days of uptime.
This leads to certain data structures on XFS (in my case order 4/order 5
allocations)  not being allocated and causes the server to stall. When
this happens either someone has to log on the server and manually invoke
the memory compaction or plain reboot the server. Before that the server
was running with the exact same workload but with 3.12.52 kernel and no
such issue were observed. That is - memory was fragmented but allocation
didn't fail, maybe alloc_pages_direct_compact was doing a better job?

FYI the allocation is performed with GFP_KERNEL | GFP_NOFS


Manual compaction usually does the job, however I'm wondering why isn't
invoking __alloc_pages_direct_compact from within __alloc_pages_nodemask
satisfying the request if manual compaction would do the job. Is there a
difference in the efficiency of manually invoking memory compaction and
the one invoked from the page allocator path?


Another question for my own satisfaction - I created a kernel module
which allocate pages of very high order - 8/9) then later when those
pages are returned I see the number of unmovable pages increase by the
amount of pages returned. So should freed pages go to the unmovable
category?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

             reply	other threads:[~2016-03-28  9:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-28  9:14 Nikolay Borisov [this message]
     [not found] ` <56F90D94.9000604@I-love.SAKURA.ne.jp>
2016-03-28 11:14   ` Nikolay Borisov
2016-03-28 11:45     ` Tetsuo Handa
2016-03-29 14:20 ` Vlastimil Babka
2016-03-29 14:53   ` Nikolay Borisov

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=56F8F5DA.6040206@kyup.com \
    --to=kernel@kyup.com \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=vbabka@suse.cz \
    /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