From: Joonsoo Kim <email@example.com> To: Michal Hocko <firstname.lastname@example.org> Cc: Aruna Ramakrishna <email@example.com>, firstname.lastname@example.org, email@example.com, Mike Kravetz <firstname.lastname@example.org>, Christoph Lameter <email@example.com>, Pekka Enberg <firstname.lastname@example.org>, David Rientjes <email@example.com>, Andrew Morton <firstname.lastname@example.org> Subject: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo stats Date: Tue, 23 Aug 2016 11:13:03 +0900 [thread overview] Message-ID: <20160823021303.GB17039@js1304-P5Q-DELUXE> (raw) In-Reply-To: <20160818115218.GJ30162@dhcp22.suse.cz> On Thu, Aug 18, 2016 at 01:52:19PM +0200, Michal Hocko wrote: > On Wed 17-08-16 11:20:50, Aruna Ramakrishna wrote: > > On large systems, when some slab caches grow to millions of objects (and > > many gigabytes), running 'cat /proc/slabinfo' can take up to 1-2 seconds. > > During this time, interrupts are disabled while walking the slab lists > > (slabs_full, slabs_partial, and slabs_free) for each node, and this > > sometimes causes timeouts in other drivers (for instance, Infiniband). > > > > This patch optimizes 'cat /proc/slabinfo' by maintaining a counter for > > total number of allocated slabs per node, per cache. This counter is > > updated when a slab is created or destroyed. This enables us to skip > > traversing the slabs_full list while gathering slabinfo statistics, and > > since slabs_full tends to be the biggest list when the cache is large, it > > results in a dramatic performance improvement. Getting slabinfo statistics > > now only requires walking the slabs_free and slabs_partial lists, and > > those lists are usually much smaller than slabs_full. We tested this after > > growing the dentry cache to 70GB, and the performance improved from 2s to > > 5ms. > > I am not opposing the patch (to be honest it is quite neat) but this > is buggering me for quite some time. Sorry for hijacking this email > thread but I couldn't resist. Why are we trying to optimize SLAB and > slowly converge it to SLUB feature-wise. I always thought that SLAB > should remain stable and time challenged solution which works reasonably > well for many/most workloads, while SLUB is an optimized implementation > which experiment with slightly different concepts that might boost the > performance considerably but might also surprise from time to time. If > this is not the case then why do we have both of them in the kernel. It > is a lot of code and some features need tweaking both while only one > gets testing coverage. So this is mainly a question for maintainers. Why > do we maintain both and what is the purpose of them. I don't know full history about it since I joined kernel communitiy recently(?). Christoph would be a better candidate for this topic. Anyway, AFAIK, first plan at the time when SLUB is introduced was to remove SLAB if SLUB beats SLAB completely. But, there are fundamental differences in implementation detail so they cannot beat each other for all the workloads. It is similar with filesystem case that various filesystems exist for it's own workload. Then, second plan was started. It is commonizing the code as much as possible to develope new feature and maintain the code easily. The code goes this direction, although it is slow. If it is achieved, we don't need to worry about maintanance overhead. Anyway, we cannot remove one without regression so we don't remove one until now. In this case, there is no point to stop improving one. Thanks.
next prev parent reply other threads:[~2016-08-23 2:07 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-17 18:20 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 [this message] 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 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=20160823021303.GB17039@js1304-P5Q-DELUXE \ --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 \ --subject='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).