mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christian Loehle <christian.loehle@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>,
	Juri Lelli <juri.lelli@redhat.com>
Cc: Qais Yousef <qyousef@layalina.io>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-pm@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH] sched/cpufreq: Use USEC_PER_SEC for deadline task
Date: Tue, 13 Aug 2024 11:17:05 +0100	[thread overview]
Message-ID: <25da50cb-776f-42db-9821-e86a441259c0@arm.com> (raw)
In-Reply-To: <CAKfTPtD_QzYVeTbQ-j2mOsKmCcjUaxo403M_HYCWbT2RjjGb7w@mail.gmail.com>

On 8/13/24 08:54, Vincent Guittot wrote:
> On Fri, 9 Aug 2024 at 09:42, Juri Lelli <juri.lelli@redhat.com> wrote:
>>
>> On 09/08/24 02:24, Qais Yousef wrote:
>>> Adding more sched folks to CC
>>>
>>> On 08/06/24 14:41, Christian Loehle wrote:
>>>> Convert the sugov deadline task attributes to use the available
>>>> definitions to make them more readable.
>>>> No functional change.
>>>>
>>>> Signed-off-by: Christian Loehle <christian.loehle@arm.com>
>>>> ---
>>>>  kernel/sched/cpufreq_schedutil.c | 6 +++---
>>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
>>>> index eece6244f9d2..012b38a04894 100644
>>>> --- a/kernel/sched/cpufreq_schedutil.c
>>>> +++ b/kernel/sched/cpufreq_schedutil.c
>>>> @@ -654,9 +654,9 @@ static int sugov_kthread_create(struct sugov_policy *sg_policy)
>>>>              * Fake (unused) bandwidth; workaround to "fix"
>>>>              * priority inheritance.
>>>>              */
>>>> -           .sched_runtime  =  1000000,
>>>> -           .sched_deadline = 10000000,
>>>> -           .sched_period   = 10000000,
>>>> +           .sched_runtime  = USEC_PER_SEC,
>>>> +           .sched_deadline = 10 * USEC_PER_SEC,
>>>> +           .sched_period   = 10 * USEC_PER_SEC,
>>>
>>> I think NSEC_PER_MSEC is the correct one. The units in
>>> include/uapi/linux/sched/types.h is not specified. Had to look at
>>> sched-deadline.rst to figure it out.

Huh, that's what I used, see below.

>>
>> In practice it's the same number :). But, you are correct, we want
>> 1ms/10ms and unit is nanoseconds, so NSEC_PER_MSEC.
> 
> Yes NSEC_PER_MSEC is the correct unit

Thank you Qais, Juri and Vincent, but if I'm not missing something we
have a contradiction.
This patch should indeed be NSEC_PER_MSEC and I'll send a v2 but:
- Documentation/scheduler/sched-deadline.rst talks about microseconds:
SCHED_DEADLINE [18] uses three parameters, named "runtime", "period", and
 "deadline", to schedule tasks. A SCHED_DEADLINE task should receive
 "runtime" microseconds of execution time every "period" microseconds, and
 these "runtime" microseconds are available within "deadline" microseconds
 from the beginning of the period.

- sched_setattr / sched_getattr manpages talks about nanoseconds:
       sched_deadline
              This field specifies the "Deadline" parameter for deadline
              scheduling.  The value is expressed in nanoseconds.

- include/uapi/linux/sched/types.h doesn't mention any unit.
I will add that to the v2 series.

- kernel/sched/deadline.c works with nanoseconds internally (although
with the precision limitation in microseconds).

No conversion so
attr->sched_deadline (uapi) == dl_se->dl_deadline (kernel) etc.
So Documentation/scheduler/sched-deadline.rst is false or what is it that
I'm missing?

  reply	other threads:[~2024-08-13 10:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-06 13:41 Christian Loehle
2024-08-09  1:24 ` Qais Yousef
2024-08-09  7:42   ` Juri Lelli
2024-08-13  7:54     ` Vincent Guittot
2024-08-13 10:17       ` Christian Loehle [this message]
2024-08-13 13:19         ` Juri Lelli
2024-08-13 13:34           ` Christian Loehle
2024-08-13 13:57             ` Juri Lelli

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=25da50cb-776f-42db-9821-e86a441259c0@arm.com \
    --to=christian.loehle@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=qyousef@layalina.io \
    --cc=rafael@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®