lkml.org 
[lkml]   [2009]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm: disable preemption in apply_to_pte_range
Peter Zijlstra wrote:
> If the lazy mmu code relies on per-cpu data, then it should be the lazy
> mmu's responsibility to ensure stuff is properly serialized. Eg. it
> should do get_cpu_var() and put_cpu_var().
>
> Those constructs can usually be converted to preemptable variants quite
> easily, as it clearly shows what data needs to be protected.
>

At the moment the lazy update stuff is inherently cpu-affine. The basic
model is that you can amortize the cost of individual update operations
(via hypercall, for example) by batching them up. That batch is almost
certainly a piece of percpu state (in Xen's case its maintained on the
kernel side as per-cpu data, but in VMI it happens somewhere under their
ABI), and so we can't allow switching to another cpu while lazy update
mode is active.

Preemption is also problematic because if we're doing lazy updates and
we switch to another task, it will likely get very confused if its
pagetable updates get deferred until some arbitrary point in the future...

So at the moment, we just disable preemption, and take advantage of the
existing work to make sure pagetable updates are not non-preemptible for
too long. This has been fine so far, because almost all the work on
using lazy mmu updates has focused on usermode mappings.

But I can see how this is problematic from your perspective. One thing
we could consider is making the lazy mmu mode a per-task property, so if
we get preempted we can flush any pending changes and safely switch to
another task, and then reenable it when we get scheduled in again.
(This may be already possible with the existing paravirt-ops hooks in
switch_to.)

In this specific case, if the lazy mmu updates / non-preemptable section
is really causing heartburn, we can just back it out for now.

J


\
 
 \ /
  Last update: 2009-02-13 18:45    [W:0.047 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site