mbox series

[0/3] xen/sched: use new idle scheduler for free cpus

Message ID 20190802130730.15942-1-jgross@suse.com (mailing list archive)
Headers show
Series xen/sched: use new idle scheduler for free cpus | expand

Message

Jürgen Groß Aug. 2, 2019, 1:07 p.m. UTC
These three patches have been carved out from my core scheduling series
as they are sufficiently independent to be applied even without the big
series.

Without this little series there are messages like the following to be
seen on the console when booting with smt=0:

(XEN) Adding cpu 1 to runqueue 0
(XEN) CPU 1 still not dead...
(XEN) CPU 1 still not dead...
(XEN) CPU 1 still not dead...
(XEN) CPU 1 still not dead...

By assigning cpus to Cpupool-0 only after all cpus are up and by not
using the more complicated credit2 scheduler for cpus not in any
cpupool this situation can simply no longer happen, as parking the not
to be started threads is done before.

Juergen Gross (3):
  xen/sched: populate cpupool0 only after all cpus are up
  xen/sched: remove cpu from pool0 before removing it
  xen/sched: add minimalistic idle scheduler for free cpus

 xen/common/cpupool.c       | 194 ++++++++++++++++++++++++++++-----------------
 xen/common/sched_credit.c  |   9 ---
 xen/common/sched_null.c    |   7 --
 xen/common/schedule.c      | 172 +++++++++++++++++++++-------------------
 xen/include/xen/sched-if.h |   2 +
 5 files changed, 213 insertions(+), 171 deletions(-)

Comments

Jürgen Groß Aug. 9, 2019, 9:47 a.m. UTC | #1
On 02.08.19 15:07, Juergen Gross wrote:
> These three patches have been carved out from my core scheduling series
> as they are sufficiently independent to be applied even without the big
> series.
> 
> Without this little series there are messages like the following to be
> seen on the console when booting with smt=0:
> 
> (XEN) Adding cpu 1 to runqueue 0
> (XEN) CPU 1 still not dead...
> (XEN) CPU 1 still not dead...
> (XEN) CPU 1 still not dead...
> (XEN) CPU 1 still not dead...
> 
> By assigning cpus to Cpupool-0 only after all cpus are up and by not
> using the more complicated credit2 scheduler for cpus not in any
> cpupool this situation can simply no longer happen, as parking the not
> to be started threads is done before.
> 
> Juergen Gross (3):
>    xen/sched: populate cpupool0 only after all cpus are up
>    xen/sched: remove cpu from pool0 before removing it
>    xen/sched: add minimalistic idle scheduler for free cpus

Would it be possible to have some feedback on this series?


Juergen
Dario Faggioli Aug. 9, 2019, 10:35 a.m. UTC | #2
On Fri, 2019-08-09 at 11:47 +0200, Juergen Gross wrote:
> On 02.08.19 15:07, Juergen Gross wrote:
> > 
> > Juergen Gross (3):
> >    xen/sched: populate cpupool0 only after all cpus are up
> >    xen/sched: remove cpu from pool0 before removing it
> >    xen/sched: add minimalistic idle scheduler for free cpus
> 
> Would it be possible to have some feedback on this series?
>
Mmm... Sorry. 

I like the idea. In fact, while looking at the core-scheduling series,
I was indeed thinking that something like this could be done. But then
I somehow missed this series.

I'll have a look today.

Regards
Dario Faggioli Aug. 13, 2019, 3:51 p.m. UTC | #3
On Fri, 2019-08-02 at 15:07 +0200, Juergen Gross wrote:
> These three patches have been carved out from my core scheduling
> series
> as they are sufficiently independent to be applied even without the
> big
> series.
> 
> Without this little series there are messages like the following to
> be
> seen on the console when booting with smt=0:
> 
> (XEN) Adding cpu 1 to runqueue 0
> (XEN) CPU 1 still not dead...
> (XEN) CPU 1 still not dead...
> (XEN) CPU 1 still not dead...
> (XEN) CPU 1 still not dead...
> 
> By assigning cpus to Cpupool-0 only after all cpus are up and by not
> using the more complicated credit2 scheduler for cpus not in any
> cpupool this situation can simply no longer happen, as parking the
> not
> to be started threads is done before.
> 
And this is not the only problem, solved by this series (or an
equivalent approach).

Right now, CPUs that are not in any pool, still belong to Pool-0's
scheduler. This forces us to make, within the scheduler, extra effort
to avoid actually running vCPUs on those.

In the case of Credit1, this also cause issue to weights
(re)distribution, as the number of CPUs available to the scheduler is
wrong.

So, we absolutely want something like this.

This is described in the changelog of commit e7191920261d ("xen:
credit2: never consider CPUs outside of our cpupool").

Would it be possible to mention this in one of the changelogs of the
series (patch 3 would be the best place, I think).

Thanks and Regards,
Dario
Jürgen Groß Aug. 26, 2019, 8:34 a.m. UTC | #4
On 13.08.19 17:51, Dario Faggioli wrote:
> On Fri, 2019-08-02 at 15:07 +0200, Juergen Gross wrote:
>> These three patches have been carved out from my core scheduling
>> series
>> as they are sufficiently independent to be applied even without the
>> big
>> series.
>>
>> Without this little series there are messages like the following to
>> be
>> seen on the console when booting with smt=0:
>>
>> (XEN) Adding cpu 1 to runqueue 0
>> (XEN) CPU 1 still not dead...
>> (XEN) CPU 1 still not dead...
>> (XEN) CPU 1 still not dead...
>> (XEN) CPU 1 still not dead...
>>
>> By assigning cpus to Cpupool-0 only after all cpus are up and by not
>> using the more complicated credit2 scheduler for cpus not in any
>> cpupool this situation can simply no longer happen, as parking the
>> not
>> to be started threads is done before.
>>
> And this is not the only problem, solved by this series (or an
> equivalent approach).
> 
> Right now, CPUs that are not in any pool, still belong to Pool-0's
> scheduler. This forces us to make, within the scheduler, extra effort
> to avoid actually running vCPUs on those.
> 
> In the case of Credit1, this also cause issue to weights
> (re)distribution, as the number of CPUs available to the scheduler is
> wrong.
> 
> So, we absolutely want something like this.
> 
> This is described in the changelog of commit e7191920261d ("xen:
> credit2: never consider CPUs outside of our cpupool").
> 
> Would it be possible to mention this in one of the changelogs of the
> series (patch 3 would be the best place, I think).

Okay.


Juergen