Re: aio-core why not using SuS? [Re: [rfc] aio-core for 2.5.29 (Re: async-io API registration for 2.5.29)]

[Andrea Arcangeli <andrea@suse.de>]

On Fri, Aug 16, 2002 at 10:12:04PM -0700, Martin J. Bligh wrote:
> Yes, I guess you'd have to TLB flush on the context switch with 
> shared mm's which you don't have to do now, and you'd use an extra

Flushing tlb across thread context switch sounds the worst part. One of
the main reasons to use threads is to avoid tlb flushing across context
switches and to reduce the context switch nearly to a longjump through
kernel space (i.e. use threads instead of segmentation to skip the tlb
flushes across context switches). If we had ASN on the x86 that wouldn't
be such a big problem, a tlb flush in the common case would just bump
the current ASN, however the main lack of the x86 architecture is the
lack of tlb tagging (hope it'll be fixed soon, it's definitely fixable
without breaking backwards compatibility so eventually some x86
hardware vendor will wakeup and the others will have to follow).  So I
would guess adding some per-VM locking like a mm->kmap_sem to serialize
the use of the per-VM pool of kmaps, sounds better unless we get address
space numbers on 32bit x86, over days of computations there are going to
be much more context switches than page faults, however it also depends
on the workload. The point about needing the tlb flush anyways for
replicated .text is valid, however not all the SMP highmem boxes are
necessiarly NUMA boxes too, and if they aren't NUMA I guess they prefer
not to flush the tlb over context switches. You may probably want to do
some measurements about the overhead of tlb flushes by adding a
__flush_tlb() in switch_to across two tasks (not across kernel threads
though) to simulate the behaviour of your proposed per-task PMD design.

Andrea