Messages in this thread | | | Date | Tue, 18 Nov 2008 17:28:58 +0000 | From | "Jan Beulich" <> | Subject | Re: 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
| |