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.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.
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).
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.