All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir (Xen.org)" <keir@xen.org>
Subject: Re: [RFC/RFT][PATCH 1 of 3] Move locking into pluggable schedulers.
Date: Wed, 23 Nov 2011 18:09:29 +0100	[thread overview]
Message-ID: <1322068169.26883.35.camel@Solace> (raw)
In-Reply-To: <1322065473.1005.151.camel@zakaz.uk.xensource.com>


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

On Wed, 2011-11-23 at 16:24 +0000, Ian Campbell wrote:
> >  struct csched_private {
> > +    /* lock for the whole pluggable scheduler, nests inside cpupool_lock */
> >      spinlock_t lock;
> >      struct list_head active_sdom;
> >      uint32_t ncpus;
> 
> Given that every scheduler plugin is going to need this lock perhaps it
> could be provided globally (but still have the responsibility for using
> it fall on the plugin)?
> 
Makes sense to me, and it should be something pretty easy to do, if you
were thinking of just moving the lock to general code.
I'm saying this because both credit and credit2 has much more payload in
their `struct csched_private', and if we also want to get rid of the
struct for them as well, that would be a different story! :-)

> I was mainly thinking of the sedf case where you add and maintain the
> whole structure for just that lock. Perhaps you have future plans which
> involve having to do that anyway in which case maybe my suggestion
> doesn't make sense.
>
I know and I agree, that 1-field-struct is just as ugly as hell! Reason
why I went for it are homogeneity with the current code of all the
schedulers, and yes, also, what you're saying above, i.e., it might turn
useful in future to have some scheduler-wide repository in sedf as it is
now for credit*. But no, I don't have _specific_ plans yet, so your
comment do make sense.

Anyway, even if we'd stay with what's in this patch, I think this at
least need some commenting...

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


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

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

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

  reply	other threads:[~2011-11-23 17:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-23 14:55 [RFC/RFT][PATCH 0 of 3] rework locking in sched_adjust Dario Faggioli
2011-11-23 15:07 ` [RFC/RFT][PATCH 1 of 3] Move locking into pluggable schedulers Dario Faggioli
2011-11-23 16:24   ` Ian Campbell
2011-11-23 17:09     ` Dario Faggioli [this message]
2011-11-23 17:30       ` Ian Campbell
2011-12-06 10:34     ` George Dunlap
2011-12-06 16:35       ` Dario Faggioli
2011-12-07 14:49     ` [PATCHv2 0 of 1] Rework locking for sched_adjust Dario Faggioli
2011-12-07 15:02       ` [PATCHv2 1 " Dario Faggioli
2011-12-14 10:24         ` George Dunlap
2011-12-07 15:04       ` [PATCHv2 0 " Dario Faggioli
2011-11-23 15:09 ` [RFC/RFT][PATCH 2 of 3] Remove VCPU pausing while adjusting domain scheduling parameters Dario Faggioli
2011-11-23 15:11 ` [RFC/RFT][PATCH 3 of 3] Introduce proper locking in sedf Dario Faggioli
2011-12-06  8:38 ` [RFC/RFT][PATCH 0 of 3] rework locking in sched_adjust Juergen Gross
2011-12-06 10:10   ` Dario Faggioli
2011-12-06 11:03     ` Juergen Gross
2011-12-06 12:30   ` George Dunlap
2011-12-06 12:39     ` Juergen Gross
2011-12-06 16:39       ` Dario Faggioli
2011-12-06 12:24 ` George Dunlap
2011-12-06 16:46   ` Dario Faggioli

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=1322068169.26883.35.camel@Solace \
    --to=raistlin@linux.it \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=juergen.gross@ts.fujitsu.com \
    --cc=keir@xen.org \
    --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.