Re: [PATCH] posix-aio-compat: fix latency issues

[Avi Kivity <avi@redhat.com>]

On 08/08/2011 03:49 PM, Frediano Ziglio wrote:
> 2011/8/8 Avi Kivity<avi@redhat.com>:
> >  In certain circumstances, posix-aio-compat can incur a lot of latency:
> >    - threads are created by vcpu threads, so if vcpu affinity is set,
> >     aio threads inherit vcpu affinity.  This can cause many aio threads
> >     to compete for one cpu.
> >    - we can create up to max_threads (64) aio threads in one go; since a
> >     pthread_create can take around 30μs, we have up to 2ms of cpu time
> >     under a global lock.
> >
> >  Fix by:
> >    - moving thread creation to the main thread, so we inherit the main
> >     thread's affinity instead of the vcpu thread's affinity.
> >    - if a thread is currently being created, and we need to create yet
> >     another thread, let thread being born create the new thread, reducing
> >     the amount of time we spend under the main thread.
> >    - drop the local lock while creating a thread (we may still hold the
> >     global mutex, though)
> >
> >  Note this doesn't eliminate latency completely; scheduler artifacts or
> >  lack of host cpu resources can still cause it.  We may want pre-allocated
> >  threads when this cannot be tolerated.
> >
> >  Thanks to Uli Obergfell of Red Hat for his excellent analysis and suggestions.
> >
> >  Signed-off-by: Avi Kivity<avi@redhat.com>
>
> Why not calling pthread_attr_setaffinity_np (where available) before
> thread creation or shed_setaffinity at thread start instead of telling
> another thread to create a thread for us just to get affinity cleared?
>

The entire qemu process may be affined to a subset of the host cpus; we 
don't want to break that.

For example:

    taskset 0xf0 qemu ....
    (qemu) info cpus
<pin individual vcpu threads to host cpus>


-- 
error compiling committee.c: too many arguments to function