| Message ID | 159070137738.12060.10928971799525755388.stgit@Palanthas (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | xen: credit2: limit the number of CPUs per runqueue | expand |
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
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
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);
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(+)