[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080118231109.GC27193@redhat.com>
Date: Fri, 18 Jan 2008 18:11:09 -0500
From: "Frank Ch. Eigler" <fche@...hat.com>
To: Arjan van de Ven <arjan@...radead.org>
Cc: "Frank Ch. Eigler" <fche@...hat.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch 2/3] Latencytop instrumentations part 1
Hi -
On Fri, Jan 18, 2008 at 02:33:34PM -0800, Arjan van de Ven wrote:
> [...]
> > Can you suggest of some reason why all this instrumentation could
> > not be in the form of standard markers (perhaps conditionally
> > compiled out if necessary)?
>
> sure. Every instrumentation you see is of the nested kind (since the lowest level
> of nesting is already automatic via wchan).
> If markers can provide me the following semantics, I'd be MORE than happy to use markers:
> [...]
> If markers can provide that semantics ... you sold me.
Further to what acme said, markers are semantics-free. Callback
functions that implement your entry & exit semantics can be attached
at run time, at your pleasure. (So can systemtap probes, for that
matter.) The main difference would be that these callback functions
would have manage the per-thread LIFO data structures themselves,
instead of allocating backpointers on the kernel stack. (Bonus marks
for not modifying task_struct. :-)
- FChE
--
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