From: Christoph Lameter <email@example.com> To: Andi Kleen <firstname.lastname@example.org> Cc: Michal Hocko <email@example.com>, Joonsoo Kim <firstname.lastname@example.org>, Aruna Ramakrishna <email@example.com>, firstname.lastname@example.org, email@example.com, Mike Kravetz <firstname.lastname@example.org>, Pekka Enberg <email@example.com>, David Rientjes <firstname.lastname@example.org>, Andrew Morton <email@example.com>, Mel Gorman <firstname.lastname@example.org>, Jiri Slaby <email@example.com> Subject: Re: what is the purpose of SLAB and SLUB Date: Wed, 24 Aug 2016 23:10:03 -0500 (CDT) [thread overview] Message-ID: <alpine.DEB.firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On Tue, 23 Aug 2016, Andi Kleen wrote: > Why would you stop someone from working on SLAB if they want to? > > Forcibly enforcing a freeze on something can make sense if you're > in charge of a team to conserve resources, but in Linux the situation is > very different. I agree and frankly having multiple allocators is something good. Features that are good in one are copied to the other and enhanced in the process. I think this has driven code development quite a bit. Every allocator has a different basic approach to storage layout and synchronization which determines performance in various usage scenarios. The competition of seeing if the developer that is a fan of one can come up with a way to make performance better or storage use more effective in a situation where another shows better numbers is good. There may be more creative ways of coming up with new ways of laying out storage in the future and I would like to have the flexibility in the kernel to explore those if necessary with additional variations. The more common code we can isolate the easier it will become to just try out a new layout and a new form of serialization to see if it provides advantages.
next prev parent reply other threads:[~2016-08-25 4:32 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 [this message] 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 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.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 \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: what is the purpose of SLAB and SLUB' \ /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).