[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1608290947140.21668@east.gentwo.org>
Date: Mon, 29 Aug 2016 09:49:09 -0500 (CDT)
From: Christoph Lameter <cl@...ux.com>
To: Michal Hocko <mhocko@...nel.org>
cc: Andi Kleen <andi@...stfloor.org>, Mel Gorman <mgorman@...e.de>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Aruna Ramakrishna <aruna.ramakrishna@...cle.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Mike Kravetz <mike.kravetz@...cle.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jiri Slaby <jslaby@...e.cz>
Subject: Re: what is the purpose of SLAB and SLUB
On Mon, 29 Aug 2016, Michal Hocko wrote:
> Compaction can certainly help and the more we are proactive in that
> direction the better. Vlastimil has already done a first step in that
> direction and we a have a dedicated kcompactd kernel thread for that
> purpose. But I guess what Mel had in mind is the latency of higher
> order pages which is inherently higher with the current page allocator
> no matter how well the compaction works. There are other changes, mostly
> for the fast path, needed to make higher order pages less of a second
> citizen.
Compaction needs to be able to move many more types of kernel objects out
of the way. I think if the callbacks that were merged for the migration of
CMA pages are made usable for slab allocations then we may make some
progress there. This would require the creator of a slab cache to specify
functions that allow the migration of an object. Would require additional
subsystem specific code. But doing that for inodes and dentries could be
very benficial for compaction.
Powered by blists - more mailing lists