[lkml]   [2009]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] mm: disable preemption in apply_to_pte_range
On Fri, 2009-02-13 at 09:24 -0800, Jeremy Fitzhardinge wrote:
> Peter Zijlstra wrote:
> >> The specific rules are that
> >> arch_enter_lazy_mmu_mode()/arch_leave_lazy_mmu_mode() require you to be
> >> holding the appropriate pte locks for the ptes you're updating, so
> >> preemption is naturally disabled in that case.
> >>
> >
> > Right, except on -rt where the pte lock is a mutex.
> >
> Hm, that's interesting. The requirement isn't really "no preemption",
> its "must not migrate to another cpu". Is there a better way to express
> that?

Not really, in the past something like migrate_disable() has been
proposed, however that's problematic in that it can generate latencies
that are _very_ hard to track down, so we've always resisted that and
found other ways.

> >> This all goes a bit strange with init_mm's non-requirement for taking
> >> pte locks. The caller has to arrange for some kind of serialization on
> >> updating the range in question, and that could be a mutex. Explicitly
> >> disabling preemption in enter_lazy_mmu_mode would make sense for this
> >> case, but it would be redundant for the common case of batched updates
> >> to usermode ptes.
> >>
> >
> > I really utterly hate how you just plonk preempt_disable() in there
> > unconditionally and without very clear comments on how and why.
> >
> Well, there's the commit comment. They're important, right? That's why
> we spend time writing good commit comments? So they get read? ;)

Andrew taught me that indeed, but still when looking at the code its
good to have some text there explaining things too.

 \ /
  Last update: 2009-02-14 10:59    [W:0.067 / U:4.080 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site