Messages in this thread | | | Date | Wed, 17 Jun 2009 11:40:16 +0200 | From | Pavel Machek <> | Subject | Re: [benchmark] 1% performance overhead of paravirt_ops on native kernels |
| |
Hi!
> > > > The "problem" is that you could in theory run out of kmap frames, since if > > > > everybody does a kmap() in an interruptible context and you have lots and > > > > lots of threads doing different pages, you'd run out. But that has nothing > > > > to do with kmap_atomic(), which is basically limited to just the number of > > > > CPU's and a (very small) level of nesting. > > > > > > This could be avoided with an anti-deadlock pool. If a task > > > attempts a nested kmap and already holds a kmap, then give it > > > exclusive access to this pool until it releases its last > > > nested kmap. > > > > We just sleep, waiting for somebody to release their. Again, that > > obviously won't work in atomic context, but it's easy enough to just have > > a "we need to have a few entries free" for the atomic case, and make it > > busy-loop if it runs out (which is not going to happen in practice > > anyway). > > The really theoretical one (which Andrew likes complaining about) is > when *everybody* is holding a kmap and asking for another one ;) > But I think it isn't too hard to make a pool for that. And yes we'd
Does one pool help?
Now you can have '*everyone* is holding the kmaps and is asking for another one'.
You could add as many pools as maximum nesting level... Is there maximum nesting level?
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |