From: Ingo Molnar <mingo@elte.hu>
To: Mathieu Desnoyers <compudj@krystal.dyndns.org>
Cc: Martin Bligh <mbligh@google.com>,
"Frank Ch. Eigler" <fche@redhat.com>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
prasanna@in.ibm.com, Andrew Morton <akpm@osdl.org>,
Paul Mundt <lethal@linux-sh.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Jes Sorensen <jes@sgi.com>, Tom Zanussi <zanussi@us.ibm.com>,
Richard J Moore <richardj_moore@uk.ibm.com>,
Michel Dagenais <michel.dagenais@polymtl.ca>,
Christoph Hellwig <hch@infradead.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
Thomas Gleixner <tglx@linutronix.de>,
William Cohen <wcohen@redhat.com>,
ltt-dev@shafik.org, systemtap@sources.redhat.com,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] Linux Kernel Markers 0.5 for Linux 2.6.17 (with probe management)
Date: Fri, 22 Sep 2006 19:12:24 +0200 [thread overview]
Message-ID: <20060922171224.GA18964@elte.hu> (raw)
In-Reply-To: <20060922171156.GA18363@Krystal>
* Mathieu Desnoyers <compudj@krystal.dyndns.org> wrote:
> * Ingo Molnar (mingo@elte.hu) wrote:
> >
> > * Mathieu Desnoyers <compudj@krystal.dyndns.org> wrote:
> >
> > > > > Then you lose the ability to trace in-kernel minor page faults.
> > > >
> > > > that's wrong, minor pagefaults go through __handle_mm_fault() just as
> > > > much.
> > > >
> > >
> > > Hi Ingo,
> > >
> > > On a 2.6.17 kernel tree :
> >
> > > It seems like a shortcut path that will never call __handle_mm_fault.
> > > This path is precisely used to handle vmalloc faults.
> >
> > yes, but you said "minor fault", not "vmalloc fault".
> >
> > minor faults are the things that happen when a task does read-after-COW
> > or read-mmap-ed-pagecache-page, and they very much go through
> > __handle_mm_fault().
> >
> > vmalloc faults are extremely rare, x86-specific and they are a pure
> > kernel-internal matter. (I'd never want to trace them, especially if it
> > pushes tracepoints into every architecture's page fault handler. I
> > implemented the initial version of them IIRC, but my memory fails
> > precisely why. I think it was 4:4 related, but i'm unsure.)
> >
> > (i now realize that above you said "in-kernel minor faults" - under that
> > you meant vmalloc faults?)
> >
>
> Yes, sorry, my mistake. This kind of fault is not as infrequent as you
> may think, as every newly allocated vmalloc region will cause vmalloc
> faults on every processes on the system that are trying to access
> them. I agree that it should not be a standard event people would be
> interested in.
most of the vmalloc area that is allocated on a typical system are
modules - and they get loaded on bootup and rarely unloaded. Even for
other vmalloc-ed areas like netfilter, the activation of them is during
bootup. So from that point on the number of vmalloc faults is quite low.
(zero on most systems) If you still want to trace it i'd suggest a
separate type of event for it.
(meanwhile i remember why i implemented vmalloc faults to begin with:
during vmalloc() we used to have a for_each_process() over all
kernel-pagetables of tasks to fix up their pagetables. This caused both
high latencies and overhead back in the days when we still were frequent
vmalloc()ers.)
Ingo
next prev parent reply other threads:[~2006-09-22 17:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-21 16:00 [PATCH] Linux Kernel Markers 0.5 for Linux 2.6.17 (with probe management) Mathieu Desnoyers
2006-09-21 16:06 ` Ingo Molnar
2006-09-21 21:42 ` Mathieu Desnoyers
2006-09-21 21:49 ` Mathieu Desnoyers
2006-09-22 6:29 ` Karim Yaghmour
2006-09-22 6:49 ` Ingo Molnar
2006-09-22 14:03 ` Mathieu Desnoyers
2006-09-22 16:53 ` Ingo Molnar
2006-09-22 17:11 ` Mathieu Desnoyers
2006-09-22 17:12 ` Ingo Molnar [this message]
2006-09-22 17:28 ` Mathieu Desnoyers
2006-09-22 7:07 ` Ingo Molnar
2006-09-22 8:14 ` Karim Yaghmour
2006-09-22 15:08 ` Mathieu Desnoyers
2006-09-22 16:24 ` Karim Yaghmour
2006-09-22 16:13 ` Mathieu Desnoyers
2006-09-22 17:03 ` Karim Yaghmour
2006-09-22 18:06 ` Mathieu Desnoyers
2006-09-22 19:24 ` Karim Yaghmour
2006-09-22 16:45 ` Ingo Molnar
2006-09-22 14:31 ` Christoph Hellwig
2006-09-23 16:51 ` Mathieu Desnoyers
2006-09-21 17:56 ` Frank Ch. Eigler
2006-09-21 18:50 ` Ingo Molnar
2006-09-21 19:54 ` Jeremy Fitzhardinge
2006-09-25 17:45 ` Frank Ch. Eigler
2006-09-21 20:59 ` Mathieu Desnoyers
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=20060922171224.GA18964@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=compudj@krystal.dyndns.org \
--cc=fche@redhat.com \
--cc=gregkh@suse.de \
--cc=hch@infradead.org \
--cc=jes@sgi.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltt-dev@shafik.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mbligh@google.com \
--cc=michel.dagenais@polymtl.ca \
--cc=prasanna@in.ibm.com \
--cc=richardj_moore@uk.ibm.com \
--cc=systemtap@sources.redhat.com \
--cc=tglx@linutronix.de \
--cc=wcohen@redhat.com \
--cc=zanussi@us.ibm.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