From: David Rientjes <rientjes@google.com>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Vasiliy Kulikov <segoon@openwall.com>,
Andrew Morton <akpm@linux-foundation.org>,
kernel-hardening@lists.openwall.com, Kees Cook <kees@ubuntu.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Christoph Lameter <cl@linux-foundation.org>,
Matt Mackall <mpm@selenic.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dan Rosenberg <drosenberg@vsecurity.com>,
Theodore Tso <tytso@mit.edu>, Alan Cox <alan@linux.intel.com>,
Jesper Juhl <jj@chaosbits.net>
Subject: Re: [kernel-hardening] Re: [RFC PATCH 2/2] mm: restrict access to /proc/slabinfo
Date: Mon, 19 Sep 2011 13:59:19 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.00.1109191350030.16739@chino.kir.corp.google.com> (raw)
In-Reply-To: <CAOJsxLE5TMXwAHPks-mvk0EPAHC18fDXf345uZ3umkzNkk7-cQ@mail.gmail.com>
On Mon, 19 Sep 2011, Pekka Enberg wrote:
> Well, sure. I was actually planning to rip out SLUB merging completely
> because it makes /proc/slabinfo so useless but never got around doing
> that.
Ripping out cache merging entirely for the benefit of an interface seems
like overkill, it actually allows the allocator to return cache-hot
objects that has a small but measurable impact on performance for some
networking loads. It would probably be better to increase awareness of
slabinfo -a and the use of slub_nomerge on the command line when debugging
issues. The most complete solution would be to move everything out of
struct kmem_cache except what is necessary for slabinfo and then point to
the actual cache data structure that could be shared by merged caches.
That's not hard to do, but would add an increment to both the alloc and
free fastpaths and require some surgery throughout all of the slub code to
understand the new data structures and that would be a pretty big patch.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-09-19 20:59 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20110910164001.GA2342@albatros>
2011-09-10 16:41 ` Vasiliy Kulikov
2011-09-12 15:06 ` Cyrill Gorcunov
2011-09-13 6:28 ` Vasiliy Kulikov
2011-09-14 13:16 ` Vasiliy Kulikov
2011-09-14 15:18 ` Dave Hansen
2011-09-14 15:42 ` [kernel-hardening] " Vasiliy Kulikov
2011-09-14 15:48 ` Vasiliy Kulikov
2011-09-14 18:24 ` Dave Hansen
2011-09-14 18:41 ` Dave Hansen
2011-09-14 19:14 ` Vasiliy Kulikov
2011-09-14 19:27 ` Kees Cook
2011-09-18 17:05 ` [kernel-hardening] " Vasiliy Kulikov
2011-09-19 13:42 ` Christoph Lameter
2011-09-19 14:30 ` Pekka Enberg
2011-09-19 14:46 ` Vasiliy Kulikov
2011-09-19 15:13 ` Pekka Enberg
2011-09-19 15:57 ` Vasiliy Kulikov
2011-09-19 16:11 ` Pekka Enberg
2011-09-19 16:18 ` Vasiliy Kulikov
2011-09-19 17:31 ` Pekka Enberg
2011-09-19 17:35 ` Vasiliy Kulikov
2011-09-19 17:51 ` Christoph Lameter
2011-09-19 19:59 ` Valdis.Kletnieks
2011-09-19 20:02 ` Christoph Lameter
2011-09-19 20:36 ` Valdis.Kletnieks
2011-09-19 17:51 ` Pekka Enberg
2011-09-19 17:58 ` Vasiliy Kulikov
2011-09-19 18:46 ` Pekka Enberg
2011-09-19 18:55 ` Vasiliy Kulikov
2011-09-19 19:20 ` Pekka Enberg
2011-09-19 19:33 ` Pekka Enberg
2011-09-19 18:55 ` Linus Torvalds
2011-09-19 19:18 ` Pekka Enberg
2011-09-19 19:45 ` Pekka Enberg
2011-09-19 20:59 ` David Rientjes [this message]
2011-09-19 18:03 ` Dave Hansen
2011-09-19 18:21 ` Pekka Enberg
2011-09-19 19:45 ` Valdis.Kletnieks
2011-09-19 19:55 ` Alan Cox
2011-09-21 17:05 ` Vasiliy Kulikov
2011-09-22 2:20 ` Valdis.Kletnieks
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.2.00.1109191350030.16739@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=alan@linux.intel.com \
--cc=cl@linux-foundation.org \
--cc=drosenberg@vsecurity.com \
--cc=gorcunov@gmail.com \
--cc=jj@chaosbits.net \
--cc=kees@ubuntu.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@cs.helsinki.fi \
--cc=segoon@openwall.com \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox