Messages in this thread |  | | | Date | Tue, 25 Jan 2011 12:47:07 -0800 | | From | Andi Kleen <> | | Subject | Re: [PATCH 00/25] mm: Preemptibility -v7 |
| |
> Its nesting hundreds of spinlocks (255+) make the preempt debug code > unhappy, it also causes fun latencies when you do start KVM/GRU > Although arguably that's the least convincing reason to do all this its > the one that got me to actually compose this series -- I really should > write a new leader.. Least Convincing is a good description... Tuning operations which only happen once is not very interesting, especially if that affects fast paths.
> Making all this preemptible also allows making the whole mmu_gather > thing preemptible, which is something we've wanted to do for a long > while, it also allows XPMEM or whatever that thing was called (Andrea > knows) and of course, it moves a part of -rt upstream.
I thought the reason for the preempt off inside the mmu gather region was to stay on the same CPU for local/remote flushes. How would it change that?
> If we decide to keep patch 24, it also simplifies the truncate path > quite a bit. That sounds like a good thing. Making truncate simpler is always good.
-Andi
|  |