linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Junwen Wu <wudaemon@163.com>
Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] sched: Fix a typo in scheduler
Date: Wed, 25 May 2022 11:16:51 -0400	[thread overview]
Message-ID: <20220525111651.6c8f8c31@gandalf.local.home> (raw)
In-Reply-To: <20220521125420.12683-1-wudaemon@163.com>

On Sat, 21 May 2022 12:54:20 +0000
Junwen Wu <wudaemon@163.com> wrote:

> Nice value is MIN_NICE(-20) to MAX_NICE(19), it better uses
> int instead of long.

First of all, the subject is completely incorrect. There's no typo to be
fixed. Second, why do you think it's better to use an int instead of long?
Long is the natural word size of an architecture.

Now perhaps for consistency, we could fix all the locations that switch
between long and int. For example, the sys_nice() definition has nice and
retval as long and are set by functions that return int. But then again,
sys_nice() returns long (and that cannot be changed).

Unless there's a real issue to be fixed (which I do not see one), I'd say
leave it as is, because this change is doing nothing but adding unnecessary
churn to the git repo.

Hence, NAK.

-- Steve


> 
> Signed-off-by: Junwen Wu <wudaemon@163.com>
> ---
>  include/linux/sched.h | 2 +-
>  kernel/sched/core.c   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 75ba8aa60248..cffc7cbed987 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1830,7 +1830,7 @@ static inline int dl_task_check_affinity(struct task_struct *p, const struct cpu
>  #endif
>  
>  extern int yield_to(struct task_struct *p, bool preempt);
> -extern void set_user_nice(struct task_struct *p, long nice);
> +extern void set_user_nice(struct task_struct *p, int nice);
>  extern int task_prio(const struct task_struct *p);
>  
>  /**
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index fcf0c180617c..15c1b63d771b 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6888,7 +6888,7 @@ static inline int rt_effective_prio(struct task_struct *p, int prio)
>  }
>  #endif
>  
> -void set_user_nice(struct task_struct *p, long nice)
> +void set_user_nice(struct task_struct *p, int nice)
>  {
>  	bool queued, running;
>  	int old_prio;


      reply	other threads:[~2022-05-25 15:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-21 12:54 [PATCH v1] sched: Fix a typo in scheduler Junwen Wu
2022-05-25 15:16 ` Steven Rostedt [this message]

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=20220525111651.6c8f8c31@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=vincent.guittot@linaro.org \
    --cc=wudaemon@163.com \
    /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;
as well as URLs for NNTP newsgroup(s).