linux-kernel - Re: [patch 1/2] mm, page_alloc: extend kernelcore and movablecore for percent

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]

Message-ID: <alpine.DEB.2.20.1802161002260.10336@nuc-kabylake>
Date:   Fri, 16 Feb 2018 10:08:28 -0600 (CST)
From:   Christopher Lameter <cl@...ux.com>
To:     Matthew Wilcox <willy@...radead.org>
cc:     Michal Hocko <mhocko@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>,
        Vlastimil Babka <vbabka@...e.cz>, Mel Gorman <mgorman@...e.de>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-doc@...r.kernel.org
Subject: Re: [patch 1/2] mm, page_alloc: extend kernelcore and movablecore
 for percent

On Fri, 16 Feb 2018, Matthew Wilcox wrote:

> On Fri, Feb 16, 2018 at 09:44:25AM -0600, Christopher Lameter wrote:
> > On Thu, 15 Feb 2018, Matthew Wilcox wrote:
> > > What I was proposing was an intermediate page allocator where slab would
> > > request 2MB for its own uses all at once, then allocate pages from that to
> > > individual slabs, so allocating a kmalloc-32 object and a dentry object
> > > would result in 510 pages of memory still being available for any slab
> > > that needed it.
> >
> > Well thats not really going to work since you would be mixing objects of
> > different sizes which may present more fragmentation problems within the
> > 2M later if they are freed and more objects are allocated.
>
> I don't understand this response.  I'm not suggesting mixing objects
> of different sizes within the same page.  The vast majority of slabs
> use order-0 pages, a few use order-1 pages and larger sizes are almost
> unheard of.  I'm suggesting the slab have it's own private arena of pages
> that it uses for allocating pages to slabs; when an entire page comes
> free in a slab, it is returned to the arena.  When the arena is empty,
> slab requests another arena from the page allocator.

This just shifts the fragmentation problem because the 2M page cannot be
released until all 4k or 8k pages within that 2M page are freed. How is
that different from the page allocator which cannot coalesce an 2M page
until all fragments have been released?

The kernelcore already does something similar by limiting the
general unmovable allocs to a section of memory.

> If you're concerned about order-0 allocations fragmenting the arena
> for order-1 slabs, then we could have separate arenas for order-0 and
> order-1.  But there should be no more fragmentation caused by sticking
> within an arena for page allocations than there would be by spreading
> slab allocations across all memory.

We avoid large frames at this point but they are beneficial to pack
objects tighter and also increase performance.

Maybe what we should do is raise the lowest allocation size instead and
allocate 2^x groups of pages to certain purposes?

I.e. have a base allocation size of 16k and if the alloc was a page cache
page then use the remainder for the neigboring pages.

Similar things could be done for the page allocator.

Raising the minimum allocation size may allow us to reduce the sizes
necessary to be allocated at the price of loosing some memory. On large
systems this may not matter much.