Re: [PATCH v10 Golden] Unified trace buffer

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 30 Sep 2008, Peter Zijlstra wrote:
> 
> Its not that complex IMHO, the thing that is ugly are those struct page
> overloads, what we could do is try and sanitize the regular struct page
> and pull all these things in.

That's not the scary part. The scary part is that somebody may well want 
to access the trace buffer pages in complex ways.

If you mmap them, for example, you can use VM_PFNMAP to make sure that 
nobody should ever look at the "struct page", but if you want to do things 
like direct-to-disk IO on the trace pages (either with splice() or with 
some kind of in-kernel IO logic), then you're officially screwed.

> Because the only reason people are doing these overloads is because
> struct page in mm_types.h is becomming an unreadable mess.

The "unreadable mess" has exactly the same issues, though: people need to 
realize that when you overload fields in the page structure, you can then 
NEVER EVER use those pages for any other thing. 

For the internal VM code, that's ok. The VM knows that a page is either an 
anonymous page or a file mapping etc, and the overloading wrt mm_types.h 
is explicit. The same goes for SL*B, although it does the overloading 
differently.

Trace buffers are different, though. Do people realize that doing the 
overloading means that you never EVER can use those buffers for anything 
else? Do people realize that it means that splice() and friends are out of 
the question?

> Trouble is, looking at it I see no easy way out,

Quite frankly, we could just put it at the head of the page itself. Having 
a "whole page" for the trace data is not possible anyway, since the trace 
header itself will always eat 8 bytes.

And I do think it would potentially be a better model. Or at least safer.

			Linus