[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4563289A.2000702@ru.mvista.com>
Date: Tue, 21 Nov 2006 19:26:02 +0300
From: Sergei Shtylyov <sshtylyov@...mvista.com>
To: Mathieu Desnoyers <compudj@...stal.dyndns.org>
Cc: Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
ltt-dev@...fik.org, mgreer@...sta.com, mlachwani@...sta.com
Subject: Re: LTTng do_page_fault vs handle_mm_fault instrumentation
Hello.
Mathieu Desnoyers wrote:
> I would like to discuss your suggestion of moving the do_page_fault
> instrumentation to handle_mm_fault. On one side, it helps removing architecture
> dependant instrumentation, but on the other hand :
> 1- We cannot access the struct pt_regs in all cases (there may be an invalid
> current task struct).
> 2- We cannot distinguish between calls to handle_mm_fault from the page fault
> handler or from get_user_pages.
> 3- Some people complain about not having enough information about the cause of
> the page fault (see the forward below).
>
> So instead of staying between my users who ask for those feature and kernel
> developers who wish to reduce the intrusiveness of instrumentation (which is a
> nice goal : moving the syscall entry/exit instrumentation do do_syscall_trace
> has helped simplifying the instrumentation), I prefer to open the discussion
> about it.
It seems I've missed the whole story behind this move.
For me, it was more a question of consistency: if we're trying to trace
all trap handlers, why not page fault one? So, I just wanted my old LTT
tracepoints back. :-)
> Ideas/comments are welcome.
> Regards,
> Mathieu
WBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists