Re: [patch 1/2] x86_64 page fault NMI-safe

[Avi Kivity]

 On 08/15/2010 07:44 PM, Mathieu Desnoyers wrote:
> * Avi Kivity (avi@xxxxxxxxxx) wrote:
> >   On 08/11/2010 05:34 PM, Steven Rostedt wrote:
> > > So, I want to allocate a 10Meg buffer. I need to make sure the kernel
> > > has 10megs of memory available. If the memory is quite fragmented, then
> > > too bad, I lose out.
> > With memory compaction, the cpu churns for a while, then you have your
> > buffer.  Of course there's still no guarantee, just a significantly
> > higher probability of success.
> The bigger the buffers, the lower the probabilities of success are. My users
> often allocate buffers as large as a few GB per cpu. Relying on compaction does
> not seem like a viable solution in this case.

Wow.  Even if you could compact that much memory, it would take quite a 
bit of time.

> > > Oh wait, I could also use vmalloc. But then again, now I'm blasting
> > > valuable TLB entries for a tracing utility, thus making the tracer have
> > > a even bigger impact on the entire system.
> > Most trace entries will occupy much less than a page, and are accessed
> > sequentially, so I don't think this will have a large impact.
> You seem to underestimate the frequency at which trace events can be generated.
> E.g., by the time you run the scheduler once (which we can consider a very hot
> kernel path), some tracing modes will generate thousands of events, which will
> touch a very significant amount of TLB entries.

Let's say a trace entry occupies 40 bytes and a TLB miss costs 200 
cycles on average.  So we have 100 entries per page costing 200 cycles; 
amortized each entry costs 2 cycles.

There's an additional cost caused by the need to re-fill the TLB later, 
but you incur that anyway if the scheduler caused a context switch.

Of course, my assumptions may be completely off (likely larger entries 
but smaller miss costs).  Has a vmalloc based implementation been 
tested?  It seems so much easier than the other alternatives.

--
error compiling committee.c: too many arguments to function

--
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/