lkml.org 
[lkml]   [2008]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-09-24 22:59    [W:0.088 / U:0.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site