linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Gioh Kim <gioh.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	jack@suse.cz, linux-fsdevel@vger.kernel.org,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
	viro@zeniv.linux.org.uk, paulmck@linux.vnet.ibm.com,
	peterz@infradead.org, adilger.kernel@dilger.ca,
	minchan@kernel.org, gunho.lee@lge.com
Subject: Re: [PATCHv4 0/3] new APIs to allocate buffer-cache with user specific flag
Date: Thu, 4 Sep 2014 23:17:35 -0400	[thread overview]
Message-ID: <20140905031735.GD1971@thunk.org> (raw)
In-Reply-To: <20140905014808.GA26070@js1304-P5Q-DELUXE>

Joonson,

Thanks for the update.  I've applied Gioh's patches to the ext4 tree,
but I'd appreciate a further clarification.  My understanding with the
problem you were trying to address is that with the current CMA
implementation, kswapd was getting activiated too early, yes?

But it would still be a good idea to try to use non-moveable memory in
preference in favor of CMA memory; even if the page migration can move
the contents of the page elsewhere, wouldn't be better to avoid
needing to do the page migation in the first place.  Given that the
ext4 file systems are getting mounted very early in the boot process,
when there should be plenty of CMA and non-CMA elegible memory
available, why was CMA memory getting selected for the buffer cache
allocations when non-CMA memory available?

In other words, even without Gioh's patch to force the use of non-CMA
eligible memory, wouldn't it be better if the memory allocator used
non-CMA preferentially if it were available.  This should be
orthogonal to whether or not kswaped gets activiated, right?

Regards,

							- Ted

  reply	other threads:[~2014-09-05  3:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1409815781-28011-1-git-send-email-gioh.kim@lge.com>
2014-09-04 22:16 ` [PATCHv4 0/3] new APIs to allocate buffer-cache with user specific flag Andrew Morton
2014-09-05  0:37   ` Gioh Kim
2014-09-05  1:14     ` Theodore Ts'o
2014-09-05  1:48       ` Joonsoo Kim
2014-09-05  3:17         ` Theodore Ts'o [this message]
2014-09-05  7:32           ` Joonsoo Kim
2014-09-05 14:14             ` Theodore Ts'o
2014-09-15  1:10               ` Joonsoo Kim
2014-09-15  6:37                 ` Minchan Kim
     [not found] ` <1409815781-28011-2-git-send-email-gioh.kim@lge.com>
2014-09-05  2:37   ` [PATCHv4 1/3] fs.c: support buffer cache allocations with gfp modifiers Theodore Ts'o
     [not found] ` <1409815781-28011-3-git-send-email-gioh.kim@lge.com>
2014-09-05  2:37   ` [PATCHv4 2/3] ext4: use non-movable memory for the ext4 superblock Theodore Ts'o
     [not found] ` <1409815781-28011-4-git-send-email-gioh.kim@lge.com>
2014-09-05  2:37   ` [PATCHv4 3/3] jbd/jbd2: use non-movable memory for the jbd superblock Theodore Ts'o

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=20140905031735.GD1971@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=gioh.kim@lge.com \
    --cc=gunho.lee@lge.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minchan@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=viro@zeniv.linux.org.uk \
    /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).