mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Christoph Lameter <clameter@sgi.com>,
	Vegard Nossum <vegard.nossum@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andi Kleen <andi@firstfloor.org>,
	Richard Knutsson <ricknu-0@student.ltu.se>
Subject: Re: [PATCH 1/2] kmemcheck v3
Date: Fri, 8 Feb 2008 09:09:39 +0100	[thread overview]
Message-ID: <20080208080939.GA11863@elte.hu> (raw)
In-Reply-To: <84144f020802072240o20ae7420x2e404e731a629c24@mail.gmail.com>


* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> On Feb 8, 2008 1:32 AM, Christoph Lameter <clameter@sgi.com> wrote:
> > But the slab layer allocates pages < PAGE_SIZE. You need to take a 
> > fault right? So each object would need its own page?
> 
> No. We allocate a shadow page for each data page which we then use as 
> a per-byte "bitmap." For every tracked _page_ we take the page fault 
> always.

it should also be made clear that not only does kmemcheck consume half 
of the RAM to do byte granular tracking of the other half of RAM, it's 
also slow, very slow, because almost every kernel-space instruction will 
generate a pagefault and then it will be single-stepped and it takes a 
debug fault as well.

That's of course totally crazy, but that's also OK and it's what makes 
the feature so interesting and powerful.

For example, when CONFIG_DEBUG_PAGEALLOC=y was introduced 5 years ago, 
it was almost unusable on modern hardware, due to the slowdown it gave. 
People said "twiddling ptes and flushing the TLB for every allocation, 
that's crazy!".

Today it can be enabled without noticing anything on a desktop, and it 
catches lots of nasty bugs.

The many debugging helpers Linux has are our eyes and ears - they catch 
stuff our real eyes did not catch. We need to sharpen these tools 
constantly, and do all the things that current hardware allows us to do 
sanely.

The same speedup will happen with kmemcheck as well in the long run. It 
is a big slowdown currently due to the massive amount of pagefaults it 
generates, even on top of the line hardware, but it's already fast 
enough to boot up and to catch bugs. [and we can optimize it by quite a 
degree - i've alreadyextended the profiler to trace kmemcheck pagefault 
sources.] It will never be usable in production, but the boundary of 
where to enable it and why will move constantly.

So i'm convinced that the time has come for kmemcheck. It already caught 
4 live kernel bugs and it's been tested on 2 boxes only. Please help us 
make the SLUB bits squeaky clean :-)

	Ingo

  reply	other threads:[~2008-02-08  8:10 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-07 21:36 Vegard Nossum
2008-02-07 21:39 ` [PATCH 2/2] " Vegard Nossum
2008-02-07 21:53 ` [PATCH 1/2] " Christoph Lameter
2008-02-07 22:12   ` Vegard Nossum
2008-02-07 22:53     ` Christoph Lameter
2008-02-07 23:18       ` Vegard Nossum
2008-02-07 23:32         ` Christoph Lameter
2008-02-08  6:40           ` Pekka Enberg
2008-02-08  8:09             ` Ingo Molnar [this message]
2008-02-08  6:30       ` Pekka Enberg
2008-02-08  6:33         ` Pekka Enberg
2008-02-08  7:10 ` Christoph Lameter
2008-02-08  7:48   ` Pekka Enberg
2008-02-08 11:55 ` Andi Kleen
2008-02-08 11:31   ` Pekka Enberg
2008-02-08 12:10     ` Andi Kleen
2008-02-08 11:39       ` Pekka Enberg
2008-02-08 11:37   ` Pekka Enberg
2008-02-08 12:15     ` Andi Kleen
2008-02-08 11:43       ` Pekka Enberg
2008-02-08 12:18   ` Vegard Nossum
2008-02-08 13:20     ` Andi Kleen
2008-02-08 12:59       ` Vegard Nossum
2008-02-08 13:48         ` Andi Kleen
2008-02-09  9:33           ` Ingo Molnar

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=20080208080939.GA11863@elte.hu \
    --to=mingo@elte.hu \
    --cc=andi@firstfloor.org \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=ricknu-0@student.ltu.se \
    --cc=vegard.nossum@gmail.com \
    /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

all inboxes | Powered by JetHome®