On 08/15/2010 07:44 PM, Mathieu Desnoyers wrote:
quoted text
> * Avi Kivity (avi@redhat.com) 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.

quoted text
>>> 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

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/