RE: architecture paper draft

[Richard J Moore <richardj_moore at uk dot ibm dot com>]

"Chen, Brad" <brad.chen@intel.com> wrote on 15/02/2005 18:37:26:

>
> > Again, comes down to purpose.  For extreme debugging then yes, being
> able
> > to insert prpobes at arbitrary locations is absolutely necessary. For
> > performance and regular tracing then not so. The extreme debugging I'm
> > referring to here is where you need to monitor for a peculiar set of
> > circumstances then force a dump (panic) when they happen.
>
> It appears to me that DTrace is specifically restricted
> to the performance problem, and as a result they have the
> useful feature of being a relatively safe tool. Perhaps
> this "safe" mode could be the default mode for systemtap,
> with a "guru" mode that allowed intercepts at arbitrary
> kernel locations?
>
> I think safety is a very important feature for being competitive
> with DTrace. I'd hate to see us come up short on safety.

Safety is not really the issue. dprobes should be as safe to use as dtrace
(other than having the ability to install a breakpoint in the middle of an
instruction if you really want to force it to do that).

I wouldn't advocate any technique that might cause the system to fail in an
unpredictable way or an intermittent way. My understanding is that dtrace
is all about dealing with the performance question and having an
appropriately simplified user interface for that purpose.

>From the debugging perspective, we need to limit to the absolute minimum
any dependence on system routines. The more dependence there is, the more
unprobeable code regions there are. If we could access paged-in memory in
user space without recourse to locking or any kernel calls then we should
allow it. They problem that Stephen has surfaced is that for the 4g/4g
kernel there will be no user page tables mapped. So it may be for this
arrangement access to user-space access is just not possible.  I am not
familiar enough with the 4g/4g mm to know how user pages are managed when
we are running in the kernel. Thinking of the top of my head, there may be
ways we can quickly locate the page table and set up a temporary mapping to
the same physical memory through an aliased kernel address, in a similar
way we do for probe insertion into user-space. We'd need to reserve one or
possibly two PTEs in kernel space for this purpose.  Note that paging in
user memory from a probe handler is absolutely not the requirement here.
Seldom is it the case the user memory of interest has been paged out. I'm
hoping that in the 4g/4g case there a good chance of finding user memory
merely unmapped.  If I'm talking nonsense - tell me -  and I'll go and read
up on the 4g/4g mm implementation.


- -
Richard J Moore
IBM Advanced Linux Response Team - Linux Technology Centre
MOBEX: 264807; Mobile (+44) (0)7739-875237
Office: (+44) (0)1962-817072