Messages in this thread | | | Date | Wed, 24 Sep 2008 13:49:24 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [RFC PATCH 1/3] Unified trace buffer |
| |
On Wed, 24 Sep 2008, Mathieu Desnoyers wrote: > > [...] Those will likely be low event-rate > situations where it is useful to take a bigger snapshot of a problematic > condition, but still to have it synchronized with the rest of the trace > data. e.g. : > > - Writing a whole video frame into the trace upon video card glitch. > - Writing a jumbo frame (up to 9000 bytes) into the buffer when a > network card error is detected or when some iptables rules (LOG, TRACE > ?) are reached. > - Dumping a kernel stack (potentially 8KB) in a single event when a > kernel OOPS is reached. > - Dumping a userspace process stack into the trace upon SIGILL, SIGSEGV > and friends.
But these are _all_ things that would be much better off with a "allocate a separate buffer, and just add a pointer to the trace".
Why? If for no other reason than the fact that we don't even want to spend lots of time to (atomically) have to copy the big data into the trace buffer!
Just allocate the buffer and fill it in (maybe it's pre-allocated already, like when a network packet event happens!) and do all of that independently of the low-level trace code. And then add the trace with the pointer.
We want the low-level trace code to be useful for things like interrupt events etc, which makes it a _disaster_ to try to add huge buffers directly to the ring buffer. You also don't want to allocate a multi-megabyte ring buffer for some odd case that happens rarely, when you can allocate the big memory users dynamically.
So limiting a trace entry to 4kB does not mean that you can't add more than 4kB to the trace - it just means that you need to have a "data indirection" trace type. Nothing more, nothing less.
[ And btw - you'd need that *anyway* for other reasons. You also don't want to have any length fields have to be 32-bit lengths etc - the length field of the trace buffer entry should be something really small like 8 or 16 bits, or even be implicit in the type for some basic event types, so that a trace event doesn't necessarily waste any bits at ALL on the length field ]
Linus
| |