public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: torvalds@transmeta.com (Linus Torvalds)
Cc: linux-kernel@vger.kernel.org, plars@austin.ibm.com, akpm@digeo.com
Subject: Re: [PATCH] Exception trace for i386
Date: 19 May 2003 23:21:42 +0200	[thread overview]
Message-ID: <p73k7cmzl7d.fsf@oldwotan.suse.de> (raw)
In-Reply-To: <1053377808.588720@palladium.transmeta.com.suse.lists.linux.kernel>

torvalds@transmeta.com (Linus Torvalds) writes:

> Please don't do it this way. For one thing, there are valid uses where
> you want to enable tracing for just one process. For another, there are
> actually cases where you may want to trace all page faults, even the
> ones that don't cause signals - kind of like normal system calls. After

x86-64 has this, (pagefault_trace), but it's usually hidden in a debug
CONFIG and not too useful in normal operation (because it generates too
much output), so I didn't port this. At one point I also did a sysctl
to echo a string into and strcmp the process ->comm against this, 
but it was a bit ugly so I removed it again.

> all, from a behavioural standpoint, that is what they are: implied
> system calls.
> 
> So I think you want to make it per-process, and expose it as a ptrace
> thing (imaging seeing all the page faults a process is taking with
> "strace". Potentially quite useful for performance tuning).

Probably, but that's not the intention of this patch. From my
experience page fault tracing is too much for printk because it
produces too much information. It needs some specialized logging
module that is optimized for high frequency logging like SGI ktrace.
It could be surely implemented, but I didn't plan to do this work
currently. If you wanted it I would suggest considering kprobes or dprobes
instead which allows to define logging macros for such things nicely already.

> I don't think it's ever really valid to expose it as a global option, as
> some programs use page faults (even the signalling kind) to do their own
> memory management, and making it a global option just makes it hard to
> work with such programs.

I especially like it being a global option. It has catched bugs on x86-64 
that were never noticed before (e.g. subprocesses silently segfaulting 
that nobody noticed doing the same on i386). Clearly it's an debugging 
thing and you definitely want an option to turn it off. But having 
the global option is useful.

Also programs that break with this are much less frequent than you
probably think.

-Andi

       reply	other threads:[~2003-05-19 21:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20030519192814.GA975@averell.suse.lists.linux.kernel>
     [not found] ` <1053377808.588720@palladium.transmeta.com.suse.lists.linux.kernel>
2003-05-19 21:21   ` Andi Kleen [this message]
2003-05-20 11:17     ` [PATCH] Exception trace for i386 Ingo Oeser
2003-05-20 12:11       ` Andi Kleen
2003-05-19 19:28 Andi Kleen
2003-05-19 20:56 ` Linus Torvalds
2003-05-19 22:24   ` Alan Cox

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=p73k7cmzl7d.fsf@oldwotan.suse.de \
    --to=ak@suse.de \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=plars@austin.ibm.com \
    --cc=torvalds@transmeta.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