linux-kernel - Re: [PATCHv4 0/3] new APIs to allocate buffer-cache with user specific flag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 5 Sep 2014 16:32:48 +0900
From:	Joonsoo Kim <iamjoonsoo.kim@....com>
To:	Theodore Ts'o <tytso@....edu>, Gioh Kim <gioh.kim@....com>,
	Andrew Morton <akpm@...ux-foundation.org>, jack@...e.cz,
	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
	paulmck@...ux.vnet.ibm.com, peterz@...radead.org,
	adilger.kernel@...ger.ca, minchan@...nel.org, gunho.lee@....com
Subject: Re: [PATCHv4 0/3] new APIs to allocate buffer-cache with user
 specific flag

On Thu, Sep 04, 2014 at 11:17:35PM -0400, Theodore Ts'o wrote:
> 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?

Hello,

Yes, similar with your understanding.

With current CMA implementation, page allocator doesn't returns
freepages in CMA reserved region until there is no freepage of movable
type. If there is no freepage of movable type, freepages in CMA reserved
region is allocated via fallback allocation. This approach is simliar
with what you suggested.

In that situation, kswapd would start to reclaim because free memory
is already too low. By this reclaim, freepages of movable type are
refilled and page allocator would stop to allocate freepages in CMA
reserved region. So, with above approach, system would work as if
it has only (total memory - CMA reserved memory) memory.

CMA is intended for using reserved memory on general purpose when
reserved memory isn't used. But current implementation don't do that.
My patch fixes this situation by allocating freepages in CMA reserved
region aggrressively.

I also test another approach, such as allocate freepage in CMA
reserved region as late as possible, which is also similar to your
suggestion and this doesn't works well. When reclaim is started,
too many pages reclaim at once, because lru list has successive pages
in CMA region and these doesn't help kswapd's reclaim. kswapd stop
reclaiming when freepage count is recovered. But, CMA pages isn't
counted for freepage for kswapd because they can't be usable for
unmovable, reclaimable allocation. So kswap reclaim too many pages
at once unnecessarilly.

More detailed explanation may be in following link.
https://lkml.org/lkml/2014/5/28/57

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/