All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Diestelhorst <sd386@cl.cam.ac.uk>
To: Ryan Harper <ryanh@us.ibm.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: scheduler independent forced vcpu selection
Date: Wed, 18 May 2005 13:10:36 +0100	[thread overview]
Message-ID: <428B30BC.8070602@cl.cam.ac.uk> (raw)
In-Reply-To: <20050517204832.GH7305@us.ibm.com>

That is a good idea, there is quite a number of other spinlock
optimisations on the way...

> I'm working on a new hypercall, do_confer, which allows the directed
> yielding of a vcpu to another vcpu.  It is mainly used when a vcpu fails
> to acquire a spinlock, yielding to the lock holder instead of spinning. I
> ported the ppc64 spinlock implementation for the i386 linux portion.  In
> implementing the hypercall, I've been trying to figure out how to get
> the scheduler (I've only played with bvt) to run the vcpu passed in the
> hypercall (after some validation) but I've run into various bad state
> situations (do_softirq pending != 0 assert, '!active_ac_timer(timer)'
> failed , and __task_on_runqueue(prev) failed) which tells me I
> don't fully understand all of the book-keeping that is needed.  Has
> anyone thought about how to do this with either BVT or the new EDF
> scheduler?

Building code similar to do_block and __enter_scheduler in
xen/common/schedule.c should be working fine, except of course running
the original scheduler, but switching directly to the hinted domain.

Are you calling do_softirq directly? If not then it is quite strange,
that this assertion fails.
The timer assertion might be the old scheduling timer, which gets
probably reset, but not deleted beforehand... And the on runqueue
assertion suggests that you are 'stealing' the domain from the
schedulers queues without giving it a chance to notice.

I'd guess cloning do_block and appending code from __enter_scheduler
with some checks (is the 'receiver' domain runnable? if not run proper
sched.do_schedule) should give you a solid base to start from.

Cheers,
  Stephan

  reply	other threads:[~2005-05-18 12:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-17 20:48 scheduler independent forced vcpu selection Ryan Harper
2005-05-18 12:10 ` Stephan Diestelhorst [this message]
2005-05-18 14:55   ` Ryan Harper
2005-05-18 18:03   ` Ryan Harper
2005-05-19 13:22     ` Stephan Diestelhorst
2005-05-18 22:37   ` Ryan Harper
2005-05-19 13:25     ` Stephan Diestelhorst
2005-05-19 14:55       ` Ryan Harper
2005-05-19 15:05       ` Ryan Harper

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=428B30BC.8070602@cl.cam.ac.uk \
    --to=sd386@cl.cam.ac.uk \
    --cc=ryanh@us.ibm.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.