[v2,3/7] xen: cpupool: add a back-pointer from a scheduler to its pool
diff mbox series

Message ID 159070137738.12060.10928971799525755388.stgit@Palanthas
State New
Headers show
Series
  • xen: credit2: limit the number of CPUs per runqueue
Related show

Commit Message

Dario Faggioli May 28, 2020, 9:29 p.m. UTC
If we need to know within which pool a particular scheduler
is working, we can do that by querying the cpupool pointer
of any of the sched_resource-s (i.e., ~ any of the CPUs)
assigned to the scheduler itself.

Basically, we pick any sched_resource that we know uses that
scheduler, and we check its *cpupool pointer. If we really
know that the resource uses the scheduler, this is fine, as
it also means the resource is inside the pool we are
looking for.

But, of course, we can do that for a pool/scheduler that has
not any been given any sched_resource yet (or if we do not
know whether or not it has any sched_resource).

To overcome such limitation, add a back pointer from the
scheduler, to its own pool.

Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
---
Cc: Juergen Gross <jgross@suse.com>
Cc: George Dunlap <george.dunlap@citrix.com>
---
Changes from v1:
* new patch
---
 xen/common/sched/cpupool.c |    1 +
 xen/common/sched/private.h |    1 +
 2 files changed, 2 insertions(+)

Comments

Jürgen Groß May 29, 2020, 2:54 p.m. UTC | #1
On 28.05.20 23:29, Dario Faggioli wrote:
> If we need to know within which pool a particular scheduler
> is working, we can do that by querying the cpupool pointer
> of any of the sched_resource-s (i.e., ~ any of the CPUs)
> assigned to the scheduler itself.
> 
> Basically, we pick any sched_resource that we know uses that
> scheduler, and we check its *cpupool pointer. If we really
> know that the resource uses the scheduler, this is fine, as
> it also means the resource is inside the pool we are
> looking for.
> 
> But, of course, we can do that for a pool/scheduler that has

s/can/can't/ ?

> not any been given any sched_resource yet (or if we do not
> know whether or not it has any sched_resource).
> 
> To overcome such limitation, add a back pointer from the
> scheduler, to its own pool.
> 
> Signed-off-by: Dario Faggioli <dfaggioli@suse.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen
Dario Faggioli May 29, 2020, 2:56 p.m. UTC | #2
On Fri, 2020-05-29 at 16:54 +0200, Jürgen Groß wrote:
> On 28.05.20 23:29, Dario Faggioli wrote:
> > If we need to know within which pool a particular scheduler
> > is working, we can do that by querying the cpupool pointer
> > of any of the sched_resource-s (i.e., ~ any of the CPUs)
> > assigned to the scheduler itself.
> > 
> > Basically, we pick any sched_resource that we know uses that
> > scheduler, and we check its *cpupool pointer. If we really
> > know that the resource uses the scheduler, this is fine, as
> > it also means the resource is inside the pool we are
> > looking for.
> > 
> > But, of course, we can do that for a pool/scheduler that has
> 
> s/can/can't/ ?
> 
And I even wrote "of course"... :-/

Yes, _of_course_, I meant can't. :-)

> Reviewed-by: Juergen Gross <jgross@suse.com>
> 
Thanks and Regards

Patch
diff mbox series

diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index 0664f7fa3d..7ea641ca26 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -287,6 +287,7 @@  static struct cpupool *cpupool_create(
         if ( c->sched == NULL )
             goto err;
     }
+    c->sched->cpupool = c;
     c->gran = opt_sched_granularity;
 
     *q = c;
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index b9a5b4c01c..df50976eb2 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -275,6 +275,7 @@  struct scheduler {
     char *opt_name;         /* option name for this scheduler    */
     unsigned int sched_id;  /* ID for this scheduler             */
     void *sched_data;       /* global data pointer               */
+    struct cpupool *cpupool;/* points to this scheduler's pool   */
 
     int          (*global_init)    (void);