On 2011-08-14 06:04, Avi Kivity wrote: > 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. At this chance: What is the state of getting rid of the remaining delta between upstream's version and qemu-kvm? Jan -- Siemens AG Corporate Technology CT T DE IT 1 Corporate Competence Center Embedded Linux Otto-Hahn-Ring 6 81739 Muenchen Tel.: +49 (89) 636-40042 Fax: +49 (89) 636-45450 mailto:jan.kiszka@xxxxxxxxxxx Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html