virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: virtualization@lists.osdl.org,
	Glauber de Oliveira Costa <glommer@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Lguest launcher, child starving parent
Date: Fri, 06 Apr 2007 13:17:56 +1000	[thread overview]
Message-ID: <1175829476.12230.677.camel@localhost.localdomain> (raw)
In-Reply-To: <1175805620.24675.9.camel@localhost.localdomain>

On Thu, 2007-04-05 at 16:40 -0400, Steven Rostedt wrote:
> Glauber noticed long delays between hitting a key, and seeing data come
> up on the virtual console.  Looking into this, I found that the
> wake_parent routine that reads from all devices was actually starving
> out the parent after sending the parent a signal to wake up.
> 
> The thing is, the child which takes the console input is recognized by
> the scheduler as an interactive process.  The parent, doesn't do so
> much, so it is recognized more as a CPU hog. So the child easily gets a
> higher priority than the parent.

Hmm, I changed the prio of the waker from "nice(19)" to "nice(5)" after
Andi complained (he still isn't happy tho).  I'll change it back for the
moment.

Unfortunately we need to keep sending signals to the parent, in order to
avoid the race between unblocking SIGUSR1 and the read() on /dev/lguest.
This is the nature of Unix signals, unfortunately.

I've been pondering restoring the original /dev/lguest interface, which
handed an fd directly into the kernel.  Then the child would just use
this fd and not send signals.  It could well improve performance, too...

Thanks for the bug report,
Rusty.

      reply	other threads:[~2007-04-06  3:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-05 20:40 [PATCH] Lguest launcher, child starving parent Steven Rostedt
2007-04-06  3:17 ` Rusty Russell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1175829476.12230.677.camel@localhost.localdomain \
    --to=rusty@rustcorp.com.au \
    --cc=glommer@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=virtualization@lists.osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).