Messages in this thread | | | Date | Sun, 15 Aug 2010 12:44:14 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [patch 1/2] x86_64 page fault NMI-safe |
| |
* 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.
> >> 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.
Thanks,
Mathieu
-- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com
| |