Re: 2.6.11-rc1-mm1

[Thomas Gleixner]

On Sun, 2005-01-16 at 21:24 -0500, Karim Yaghmour wrote:

> > Sorting out disabled events in the hot path and moving the if
> > (pid/gid/grp) whatever stuff into userspace postprocessing is not an
> > alien request.
> 
> It is. Have you even read what I suggested to change in my other mail:
> if ((any_filtering) && !(ltt_filter(event_id, event_struct, data)))
> 	return -EINVAL;

Sorting out disabled events is the filtering you have to do in kernel
and you should do it in the hot path or remove the unneccecary
tracepoints at compiletime. 

> > 4096kB/sec for  64 events/ms (event frequency  64kHz) (15 us)
> > 8192kB/sec for 128 events/ms (event frequency 128kHz) ( 8 us) 

> Actually, on a PII-350MHz, I was already generating 0.5MB/s of data
> just by running an X session. If we assume that a machine 10 times
> faster generates 10 times as many events, we've already got 5MB/s,
> and I'm sure that there are heavier cases than X.

You are not answering my argument. 8MB/sec is an event frequency of
128hz when we assume 64byte/event. It's one event every 8us. So every
unneccecary computation, every leaving the hotpath for nothing is just
giving you performance loss.

> Not even Ingo hinted at getting rid of filtering. Remember the earlier
> e-mail I refered to? Here's what he was suggesting:

I said:
> > Sorting out disabled events in the hot path 

s/Sorting/Filtering/

I never said this should not be done.

> Like I said, we are willing to accomodate those who want to be able
> to use relayfs for kernel debugging purposes, but we can hardly
> be blamed for not making LTT a generic kernel debugging tool as this
> is exactly the excuse many kernel developers had for not including
> LTT to start with. It's just totally dissengenious for giving us
> grief for claiming that we are doing something and then later turn
> around and blame us for not doing it ... cheesh ...

Seperating layers as I suggested before is not making it a generic
debugging tool. It makes parts of those layers available for other usage
and gives us the chance to reuse the parts for cleaning up already
available code which has the same hardwired structure.

tglx



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/