From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42563) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6221-0004XE-Ji for qemu-devel@nongnu.org; Tue, 20 Sep 2011 11:14:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R621z-0002ap-IA for qemu-devel@nongnu.org; Tue, 20 Sep 2011 11:14:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R621z-0002ae-83 for qemu-devel@nongnu.org; Tue, 20 Sep 2011 11:14:43 -0400 Message-ID: <4E78ADDF.5010102@redhat.com> Date: Tue, 20 Sep 2011 17:14:39 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <4E78A2ED.50401@siemens.com> <4E78A7B5.6090607@redhat.com> <4E78AA84.7050702@siemens.com> In-Reply-To: <4E78AA84.7050702@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qxl: pthread_yield on QXL_IO_NOTIFY_OOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel On 09/20/11 17:00, Jan Kiszka wrote: > On 2011-09-20 16:48, Gerd Hoffmann wrote: >> On 09/20/11 16:27, Jan Kiszka wrote: >>> Hi Gerd, >>> >>> can you (or anyone familiar with those bits) comment on pthread_yield() >>> in ioport_write() of hw/qxl.c? Which threads are supposed to run this >>> way? >> >> spice server thread. >> >>> Can't this relation be expressed explicitly? >> >> The thread is created by libspice-server, so we don't have a handle for it. > > And also no communication channel to kick? There is a pipe, and qxl_spice_oom() will kick that way. I think the yield tries to avoid that kick in case the spice server thread is already busy processing stuff. I'm not fully sure though, the code predates /me working on spice. Each time I look at that piece of code I'm asking myself whenever it actually has a positive effect and I somehow doubt it. I never found the time for deeper investigation though. >> Good question. I'm tempted to just rip it out and run qxl_spice_oom() >> unconditionally. The yield thing is best effort only anyway, there is >> no guarantee that the spice server thread actually gets scheduled and >> puts some stuff into the release ring. > > And the issue with sleeping is that we stall the vcpu. So just reporting > oom is likely better. Agree on that. cheers, Gerd