Re: arch_flush_lazy_mmu_mode() in arch/x86/mm/highmem_32.c

["Jan Beulich" <jbeulich@novell.com>]

>>> Jeremy Fitzhardinge <jeremy@goop.org> 18.11.08 18:01 >>>
>Yes, it disables interrupts while its actually issuing the multicall.  I 
>don't think that matters much, since the multicall itself can't be 
>preempted (can it?) and the rest of the code is very short.  Originally 
>it disabled interrupts for the entire lazy section, which is obviously 
>worse.

If an interrupt (event) comes in, a multicall could of course be 'preempted',
in order to service the event. But of course that works only if event
delivery isn't disabled.

>> There's no reason to do any flush at all if you suppress batching temporarily.
>> And it only needs (would need) explicit suppressing here because you can't
>> easily recognize being in the context of a page fault handler from the
>> batching functions (other than recognizing being in the context of an
>> interrupt handler, which is what would allow removing the flush calls from
>> highmem_32.c).
>
>I'm not sure what your concern is here.  If batching is currently 
>enabled, then the flush will push out anything pending immediately.  If 
>batching is disabled, then the flush will be a noop and return immediately.

Latency, as before. The page fault should have to take longer than it really
needs, and the flushing of a pending batch clearly doesn't belong to the
page fault itself.

Jan