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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:36 EST