xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Keir Fraser <keir.xen@gmail.com>
To: James Harper <james.harper@bendigoit.com.au>,
	xen devel <xen-devel@lists.xensource.com>
Subject: Re: unfair servicing of DomU vbd requests
Date: Thu, 03 Mar 2011 07:29:55 +0000	[thread overview]
Message-ID: <C994F3F3.14124%keir.xen@gmail.com> (raw)
In-Reply-To: <AEC6C66638C05B468B556EA548C1A77D01C55B90@trantor>

On 03/03/2011 02:25, "James Harper" <james.harper@bendigoit.com.au> wrote:

> A user of GPLPV (see thread "blue screen in windows balloon driver") is
> getting a bug check in Windows under extremely high memory usage and
> swapfile thrashing tests across multiple DomU's. Responses to my query
> on the ntdev mailing list say that this would happen if an IO request is
> not completed after 70 seconds during high memory/pagefile pressure,
> which is what is happening.
> 
> It appears that Dom0 is not servicing vbd requests from DomU's fairly so
> one or two end up getting stalled while the others are mostly okay. How
> are vbd requests supposed to be serviced? Is there potential for one to
> be overlooked for a long period of time? Is there some settings that
> could be changed to avoid this happening?

Dom0 does round-robin scanning of pending event channels these days, which
helps fairness a fair bit. When a pending event is found, the corresponding
blkfront has a batch of requests pulled down and submitted into Linux's
block subsystem at which point we have no more control over scheduling (it
could generally be configured though -- Linux has an admin mechanism for
that).

 -- Keir

> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

  reply	other threads:[~2011-03-03  7:29 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-03  2:25 unfair servicing of DomU vbd requests James Harper
2011-03-03  7:29 ` Keir Fraser [this message]
2011-03-03  8:22   ` Ian Campbell
2011-03-03  8:28     ` James Harper
2011-03-03  8:30       ` Keir Fraser
2011-03-03 17:09         ` [GIT/PATCH 0/5] " Ian Campbell
2011-03-03 17:10           ` [PATCH 1/5] xen: events: Process event channels notifications in round-robin order Ian Campbell
2011-03-03 17:10           ` [PATCH 2/5] xen: events: Make last processed event channel a per-cpu variable Ian Campbell
2011-03-09 20:32             ` Konrad Rzeszutek Wilk
2011-03-09 20:40               ` Ian Campbell
2011-03-09 20:47                 ` Jeremy Fitzhardinge
2011-03-10  8:30                   ` Ian Campbell
2011-03-11 17:46                     ` Jeremy Fitzhardinge
2011-03-03 17:10           ` [PATCH 3/5] xen: events: Clean up round-robin evtchn scan Ian Campbell
2011-03-03 17:10           ` [PATCH 4/5] xen: events: Make round-robin scan fairer by snapshotting each l2 word Ian Campbell
2011-03-03 17:10           ` [PATCH 5/5] xen: events: Remove redundant clear of l2i at end of round-robin loop Ian Campbell
2011-03-04  8:40           ` [GIT/PATCH 0/5] Re: unfair servicing of DomU vbd requests John Weekes
2011-03-04  9:15             ` Ian Campbell
2011-03-07 19:33               ` John Weekes

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=C994F3F3.14124%keir.xen@gmail.com \
    --to=keir.xen@gmail.com \
    --cc=james.harper@bendigoit.com.au \
    --cc=xen-devel@lists.xensource.com \
    /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).