Messages in this thread | | | Subject | Re: [PATCH] Allow preemption during lazy mmu updates | From | Peter Zijlstra <> | Date | Sat, 28 Mar 2009 00:48:20 +0100 |
| |
On Fri, 2009-03-27 at 11:02 -0700, Jeremy Fitzhardinge wrote: > Hi all, > > We discussed this series a while ago. The specific problem > was the need to disable preemption in apply_to_pte_range when using > lazy mmu updates around the callback function. When used on usermode > addresses there was no problem because it needs to take the pte > lock anyway, but there's no requirement for taking a pte lock when > updating kernel ptes, so it ended up adding a new no-preempt region. > > The gist of the series is that if we get preempted while doing an mmu > update, we flush all the pending updates and switch to the next task. > We record that the task was doing a lazy mmu update in its task flags, > and resume lazy updates when we switch back. > > All the context-switch time activity happens in the existing > context-switch pvops calls, so there's no cost to non-pvops systems, > or to pvops backends which don't use lazy mmu updates. > > I don't think there were any objections to this series, but Ingo would > like to see an Acked by from someone since it gets into the mm side > of things. > > (The first patch in the series adds the required preempt disable/enable > and then the rest of the series removes them again. I think the first > patch is already in mm-.)
Looks good from my POV
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
| |