From: Christoph Lameter <firstname.lastname@example.org> To: Mel Gorman <email@example.com> Cc: Michal Hocko <firstname.lastname@example.org>, Joonsoo Kim <email@example.com>, Aruna Ramakrishna <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Mike Kravetz <email@example.com>, Pekka Enberg <firstname.lastname@example.org>, David Rientjes <email@example.com>, Andrew Morton <firstname.lastname@example.org>, Jiri Slaby <email@example.com> Subject: Re: what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats Date: Thu, 25 Aug 2016 14:55:43 -0500 (CDT) [thread overview] Message-ID: <alpine.DEB.firstname.lastname@example.org> (raw) In-Reply-To: <20160825100707.GU2693@suse.de> On Thu, 25 Aug 2016, Mel Gorman wrote: > Flipping the lid aside, there will always be a need for fast management > of 4K pages. The primary use case is networking that sometimes uses > high-order pages to avoid allocator overhead and amortise DMA setup. > Userspace-mapped pages will always be 4K although fault-around may benefit > from bulk allocating the pages. That is relatively low hanging fruit that > would take a few weeks given a free schedule. Userspace mapped pages can be hugepages as well as giant pages and that has been there for a long time. Intermediate sizes would be useful too in order to avoid having to keep lists of 4k pages around and continually scan them. > Dirty tracking of pages on a 4K boundary will always be required to avoid IO > multiplier effects that cannot be side-stepped by increasing the fundamental > unit of allocation. Huge pages cannot be dirtied? This is an issue of hardware support. On x867 you only have one size. I am pretty such that even intel would support other sizes if needed. The case has been repeatedly made that 64k pages f.e. would be useful to have on x86. > Batching of tree_lock during reclaim for large files and swapping is also > relatively low hanging fruit that also is doable in a week or two. Ok these are good incremental improvement but they do not address the main issue going forward. > A high-order per-cpu cache for SLUB to reduce zone->lock contention is > also relatively low hanging fruit with the caveat it makes per_cpu_pages > larger than a cache line. Would be great to have. > If you want to rework the VM to use a larger fundamental unit, track > sub-units where required and deal with the internal fragmentation issues > then by all means go ahead and deal with it. Hmmm... The time problem is always there. Tried various approaches over the last decade. Could be a massive project. We really would need a larger group of developers to effectively do this.
next prev parent reply other threads:[~2016-08-25 19:56 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-17 18:20 [PATCH v3] mm/slab: Improve performance of gathering slabinfo stats Aruna Ramakrishna 2016-08-17 19:03 ` Eric Dumazet 2016-08-17 19:25 ` Aruna Ramakrishna 2016-08-18 11:52 ` Michal Hocko 2016-08-19 5:47 ` aruna.ramakrishna 2016-08-23 2:13 ` Joonsoo Kim 2016-08-23 15:38 ` what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats Michal Hocko 2016-08-23 15:54 ` what is the purpose of SLAB and SLUB Andi Kleen 2016-08-25 4:10 ` Christoph Lameter 2016-08-25 7:32 ` Michal Hocko 2016-08-25 19:49 ` Christoph Lameter 2016-08-24 1:15 ` what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats Joonsoo Kim 2016-08-24 8:05 ` Michal Hocko 2016-08-24 8:20 ` Mel Gorman 2016-08-25 4:01 ` Christoph Lameter 2016-08-25 10:07 ` Mel Gorman 2016-08-25 19:55 ` Christoph Lameter [this message] 2016-08-26 20:47 ` what is the purpose of SLAB and SLUB Andi Kleen 2016-08-29 13:44 ` Michal Hocko 2016-08-29 14:49 ` Christoph Lameter 2016-08-30 9:39 ` what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats Mel Gorman 2016-08-30 19:32 ` Christoph Lameter
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=alpine.DEB.email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats' \ /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
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).