xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Dario Faggioli <dfaggioli@suse.com>
To: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
	"Wei Liu" <wl@xen.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Ian Jackson" <ian.jackson@eu.citrix.com>,
	"Tim Deegan" <tim@xen.org>, "Julien Grall" <julien.grall@arm.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/sched: rework and rename vcpu_force_reschedule()
Date: Tue, 17 Sep 2019 16:33:05 +0200	[thread overview]
Message-ID: <04ddefb4e66b349135631bd6dd63f3091d0707ec.camel@suse.com> (raw)
In-Reply-To: <20190914064217.4877-1-jgross@suse.com>


[-- Attachment #1.1: Type: text/plain, Size: 2426 bytes --]

On Sat, 2019-09-14 at 08:42 +0200, Juergen Gross wrote:
> vcpu_force_reschedule() is only used for modifying the periodic timer
> of a vcpu. Forcing a vcpu to give up the physical cpu for that
> purpose
> is kind of brutal.
> 
> So instead of doing the reschedule dance just operate on the timer
> directly. By protecting periodic timer modifications against
> concurrent
> timer activation via a per-vcpu lock it is even no longer required to
> bother the target vcpu at all for updating its timer.
> 
> Rename the function to vcpu_set_periodic_timer() as this now reflects
> the functionality.
> 
Personally, I'm rather happy to see the code which was doing that very
weird "let's go through rescheduling" dance going away. I, FWIW, never
understood why periodic timer handling was implemented that way (and
looking back at relevant changelogs does not help).

The code, as it results after applying this patch, is a lot better, and
easier to understand.

Performance and scalability wise, I don't have benchmarks for this
specific patch (but the ones I did included it, as it back then was
part of the core-scheduling series), but I agree with Juergen. I.e., I
think the patch is either neutral or, if it does something, it improves
things.

Furthermore, periodic timer is *not* used any longer (and since quite
some time/kernel versions). Basically, all we do with the periodic
timer is to disable it during boot. At least for Linux, but I think
this is the case for FreeBSD too. So, even if the patch would have a
negative impact (which again I don't think it's the case), we probably
won't see them.

On this grounds (and, of course, on the one that I've looked at the
code, and think it's correct), for the scheduling part:

> Signed-off-by: Juergen Gross <jgross@suse.com>
>
Reviewed-by: Dario Faggioli <dfaggioli@suse.com>

Then, if some words about the outcome of the discussion in this thread,
e.g., a mention to the fact that the old code wasn't really lockless,
and that the new code is a lot more straightforward, it'd be even
better.

But my Rev-by stands, with or without this.

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

      parent reply	other threads:[~2019-09-17 14:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-14  6:42 [Xen-devel] [PATCH v2] xen/sched: rework and rename vcpu_force_reschedule() Juergen Gross
2019-09-16  9:20 ` Jan Beulich
2019-09-16 12:49   ` Juergen Gross
2019-09-16 14:39     ` Jan Beulich
2019-09-16 17:23       ` Juergen Gross
2019-09-17 14:33 ` Dario Faggioli [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=04ddefb4e66b349135631bd6dd63f3091d0707ec.camel@suse.com \
    --to=dfaggioli@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=julien.grall@arm.com \
    --cc=konrad.wilk@oracle.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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).