linux-kernel - Re: tbench regression - Why process scheduler has impact on tbench and why small per-cpu slab (SLUB) cache creates the scenario?

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: <Pine.LNX.4.64.0709141242200.17369@schroedinger.engr.sgi.com>
Date:	Fri, 14 Sep 2007 12:51:34 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	"Siddha, Suresh B" <suresh.b.siddha@...el.com>
cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, mingo@...e.hu,
	Mel Gorman <mel@...net.ie>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Matthew.R.wilcox@...el.com
Subject: Re: tbench regression - Why process scheduler has impact on tbench
 and why small per-cpu slab (SLUB) cache creates the scenario?

On Fri, 14 Sep 2007, Siddha, Suresh B wrote:

> Numbers I posted in the previous e-mail is the only story we have so far.

It would be interesting to know more about how the allocator is used 
there.

> Sorry, These systems are huge and limited. We are raising the priority
> with the performance team to do the latest slub patch testing.

Ok. Thanks.

> > Its too late for 2.6.23. But we can certainly do things for .24. Could you 
> > please test the patches queued up in Andrew's tree? In particular the page 
> > allocator pass through and the per cpu structures optimizations?
> 
> We are trying to get the latest data with 2.6.23-rc4-mm1 with and without
> slub. Is this good enough?

Good enough. If you are concerned about the page allocator pass through 
then you may want to test the page allocator pass through patchset 
separately. The fastpath of the page allocator is currently not 
competitive if you always free and allocate a single page. If contiguous 
pages are allocated then the pass through is superior.

> > The work of Matheiu also has implications for the page allocator. We may 
> > be able to significantly speed up the fastpath there as well.
> 
> Ok. Atleast till all the regressions addressed and all these patches well
> tested, we shouldn't do away with slab from mainline anytime soon.

Ok. We will hold off. It was so silent about this issue though and from 
the talk with Corey I may have wrongly concluded that this was because the 
issues were resolved.

> Other than us, who else are you banking on for analysing slub? Do
> you have any numbers that you can share, which show where slub
> is good or bad...

http://lwn.net/Articles/246927/ contains some cycle measurements for the 
per cpu patchset and also for the page allocator pass through.

If there is a problem with certain sizes for page allocator pass through 
then we may want to increase the boundary so that the page allocator is 
only called for objects larger than page size.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/