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.0709050342520.8127@schroedinger.engr.sgi.com>
Date:	Wed, 5 Sep 2007 03:45:58 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
cc:	LKML <linux-kernel@...r.kernel.org>, mingo@...e.hu
Subject: Re: tbench regression - Why process scheduler has impact on tbench
 and why small per-cpu slab (SLUB) cache creates the scenario?

On Wed, 5 Sep 2007, Zhang, Yanmin wrote:

> > > However, the approach treats the slabs in the same policy. Could we
> > > implement a per-slab specific approach like direct b)?
> > 
> > I am not sure what you mean by same policy. Same configuration for all 
> > slabs?
> Yes.

Ok. I could add the ability to specify parameters for some slabs.

> > Would it be possible to try the two other approaches that I suggested? I 
> > think both of those may also solve the issue. Try booting with
> > slab_max_order=0
> 1) I tried slab_max_order=0 and the regression becomes 12.5%. It's still 
> not good.
> 
> 2) I apllied patch 
> slub-direct-pass-through-of-page-size-or-higher-kmalloc.patch to kernel 
> 2.6.23-rc4. The new testing result is much better, only 1% less than 
> 2.6.22.

Ok. That seems to indicate that we should improve the alloc path in the 
page allocator. The page allocator performance needs to be competitive on 
page sized allocations. The problem will be largely going away when we 
merge the pass through patch in 2.6.24.
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ