lkml.org 
[lkml]   [2008]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: arch_flush_lazy_mmu_mode() in arch/x86/mm/highmem_32.c
>>> 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



\
 
 \ /
  Last update: 2008-11-18 18:31    [W:0.034 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site