Re: 2.6.11-rc1-mm1

[Roman Zippel]

Hi,

On Mon, 17 Jan 2005, Karim Yaghmour wrote:

> > Periodically can also mean a buffer start call back from relayfs 
> > (although that would mean the first entry is not guaranteed) or a 
> > (per cpu) eventcnt from the subsystem. The amount of needed search would 
> > be limited. The main point is from the relayfs POV the buffer structure 
> > has always the same (simple) structure.
> 
> But two e-mails ago, you told us to drop the start_reserve and end_reserve
> and move the details of the buffer management into relayfs and out of
> ltt? Either we have a callback, like you suggest, and then we need to
> reserve some space to make sure that the callback is guaranteed to have
> the first entry, or we drop the callback and provide an option to the
> user for relayfs to write this first entry for him. Providing a callback
> without reservation is no different than relying purely on the heartbeat,
> which, like I said before and for the reasons illustrated below, is
> unrealistic.

Why is so important that it's at the start of the buffer? What's wrong 
with a special event _near_ the start of a buffer?

> > Why is it "totally unrealistic"?
> 
> Ok, let's expand a little here on the amount of data. Say you're getting
> 2MB/s of data (which is not unrealistic on a loaded system.) That means
> that if I'm tracing for 2 days, I've got 345GB of data (~7.5GB/hour).
> In practice, users aren't necessarily interested in plowing through the
> entire 345GB, they just want to view a given portion of it. Now, if I
> follow what you are suggesting, I have to go through the entire 345GB to:
> a) create indexes, b) reorder events, and likely c) have to rewrite
> another 345GB of data. And I haven't yet discussed the kind of problems
> you would encounter in trying to reorder such a beast that contains,
> by definition, variable-sized events. For one thing, if event N+1 doesn't
> follow N, then you would be forced to browse forward until you actually
> found it before you could write a properly ordered trace. And it just
> takes a few processes that are interrupted and forced to sleep here and
> there to make this unusable. That's without the RAM or fs space required
> to store those index tables ... At 3 to 12 bytes per events, that's a lot
> of space for indexes ...
> 
> If I keep things as they are with ordered events and delimiters on buffer
> boundaries, I can skip to any place within this 345GB and start processing
> from there.

What gives you the idea, that you can't do this with what I proposed?
You can still seek freely within the data at buffer boundaries and you 
only have to search a little into the buffer to find the delimiter. Events 
are not completely at random, so that the little reordering can be done at 
runtime. Sorry, but I don't get what kind of unsolvable problems you see 
here.

> Rhetorical: Couldn't the ad-hoc mode case be a special case of the
> managed mode?

Wrong question. What compromises can be made on both sides to create a 
common simple framework? Your unwillingness to compromise a little on the 
ltt requirements really amazes me.

bye, Roman
-
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/