linux-kernel - Re: [RFC] i386: Remove page sized slabs for pgds and pmds

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.0703281636400.14657@schroedinger.engr.sgi.com>
Date:	Wed, 28 Mar 2007 16:44:01 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	William Lee Irwin III <wli@...omorphy.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] i386: Remove page sized slabs for pgds and pmds

On Wed, 28 Mar 2007, William Lee Irwin III wrote:

> As far as kernel compiles being relevant to anything besides
> potentially optimizing a particular major benchmark using gcc as one
> of its components... yeah, right. It's too macro to be a microbenchmark
> of anything and too micro to be pertinent to any meaningful
> macrobenchmark such as those from major benchmark publishers (who can't
> be named for trademark/etc. reasons). Hasn't it been at least 5 years
> since people figured out kernel compiles were complete bulls**t as
> benchmarks along with dbench for other reasons and several others? If
> not, I don't know why I bother with this kernel at all.

All benchmarks have their specific drawbacks. I personally like to do code 
review and see what cachelines are touched but that is basically imagining 
what a cpu does. Ones thinking may be led astray.

> Even so, I already did this and am done with it. It's not like I'm
> not carrying around numerous patches I know will never be merged all
> the time anyway. If you want to back it all out so badly, just do it
> and stop bothering me about it, and I'll merely continue maintaining my
> local patches without ever posting them as I have been for years. I'm
> not at all happy with the NIH situation, either, not that I'm at such a
> loss for ideas to need to contest every petty NIH that flies past.

What is NIH? My main concern is to get the use of page struct fields of 
the slab removed. We have to do special things to page sized allocs 
because of these page struct uses. F.e. the private field is used by 
compound pages and if any of the slabs allocate a higher order page that 
field will be in use.

We certainly see even from the rudimentary tests that I have done that 
the limited pgd, pmd caching has some effect. Could we please see your local 
patches? And I guess that you must have some sort of benchmark that you 
run to test these?
-
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/