|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] sched: print information about scheduler granularity
On 17/04/2020 08:57, Jürgen Groß wrote:
> On 16.04.20 18:43, Dario Faggioli wrote:
>> On Thu, 2020-04-16 at 09:33 +0100, Sergey Dyasli wrote:
>>> Currently it might be not obvious which scheduling mode is being used
>>> by the scheduler. Alleviate this by printing additional information
>>> about the selected granularity.
>>>
>> I like the idea. However, I don't like how verbose and long that line
>> becomes.
>>
>>> Messages now look like these:
>>>
>>> 1. boot
>>> (XEN) [00089808f0ea7496] Using scheduler: SMP Credit Scheduler
>>> (credit) in core-scheduling mode
>>>
>>> 2. xl debug-keys r
>>> (XEN) [ 45.914314] Scheduler: SMP Credit Scheduler (credit) in 2-
>>> way core-scheduling mode
>>>
>> What about adding an entry, just below these ones. Something looking
>> like, for instance (both at boot and in the debug-key dump):
>>
>> "Scheduling granularity: cpu"
>>
>> (or "core", or "socket")
I agree that the line becomes too long. I'll print the new information
on a separate line as you suggest in v2.
>>
>> Also
>>
>>> --- a/xen/common/sched/cpupool.c
>>> +++ b/xen/common/sched/cpupool.c
>>> @@ -38,7 +38,35 @@ static cpumask_t cpupool_locked_cpus;
>>> static DEFINE_SPINLOCK(cpupool_lock);
>>> static enum sched_gran __read_mostly opt_sched_granularity =
>>> SCHED_GRAN_cpu;
>>> -static unsigned int __read_mostly sched_granularity = 1;
>>> +static unsigned int __read_mostly sched_granularity;
>>> +
>>> +char *sched_gran_str(char *str, size_t size)
>>> +{
>>> + char *mode = "";
>>> +
>>> + switch ( opt_sched_granularity )
>>> + {
>>> + case SCHED_GRAN_cpu:
>>> + mode = "cpu";
>>> + break;
>>> + case SCHED_GRAN_core:
>>> + mode = "core";
>>> + break;
>>> + case SCHED_GRAN_socket:
>>> + mode = "socket";
>>> + break;
>>> + default:
>>> + ASSERT_UNREACHABLE();
>>> + break;
>>> + }
>>> +
>>> + if ( sched_granularity )
>>> + snprintf(str, size, "%u-way %s", sched_granularity, mode);
>>>
>> I'm not sure about using the value of the enum like this.
>
> enum? sched_granularity holds the number of cpus per scheduling
> resource. opt_sched_granularity is the enum.
>
>>
>> E.g., in a system with 4 threads per core, enabling core scheduling
>> granularity would mean having 4 vCPUs in the scheduling units. But this
>> will still print "2-way core-scheduling", which I think would sound
>> confusing.
>
> It would print "4-way", of course.
>
>>
>> So I'd just go with "cpu", "core" and "socket" strings.
>
> No, this is not a good idea. With e.g. smt=0 you'll be able to have
> "1-way core" which is much more informative than "core".
Can confirm the above. "sched-gran=core" on a Knights Mill produces:
(XEN) [ 232.018648] Scheduler: SMP Credit Scheduler (credit) in 4-way
core-scheduling mode
While "sched-gran=core smt=0" gives:
(XEN) [ 259.337588] Scheduler: SMP Credit Scheduler (credit) in 1-way
core-scheduling mode
--
Thanks,
Sergey
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |