On Wed, Jun 18, 2025 at 03:04:40PM +0530, Madadi Vineeth Reddy wrote:
> Hi Benno, Karel
>
> On 18/06/25 14:55, Karel Zak wrote:
> > On Wed, Jun 18, 2025 at 11:18:18AM +0200, Karel Zak wrote:
> >> On Wed, Jun 18, 2025 at 10:18:29AM +0200, Benno Schulenberg wrote:
> >>>
> >>> Op 17-06-2025 om 20:24 schreef Madadi Vineeth Reddy:
> >>>> Currently, chrt requires a priority argument even for scheduling
> >>>> policies like SCHED_OTHER and SCHED_BATCH, which ignore it.
> >>>>
> >>>> This change relaxes that requirement. Now, priority is only expected
> >>>> for SCHED_FIFO and SCHED_RR. For other policies, a default value of 0
> >>>> is set internally and no argument is required on the command line.
> >>>
> >>> Doesn't this alter the "show-the-current-policy-and-priority" behavior
> >>> when no priority is given? Currently `./chrt --help` says (trimmed):
> >>
> >> Very good point. The priority policy (--{other,...}) should be
> >> required to ensure that the user wants to alter the setting rather
> >> than print the current situation. Madadi, what do you think?
> >
> > Ah, I now read Benno's note more carefully. The code just silently ignores
> > policy when priority is not specified.
> >
> > $ chrt --fifo --pid $$
> > pid 994013's current scheduling policy: SCHED_OTHER
> > pid 994013's current scheduling priority: 0
> >
> > This is ugly. The question is how important it is to support this for
> > backward compatibility. I'd assume that users use "chrt --pid $$" to get
> > the current setting.
> >
>
> chrt --pid 20570
> pid 20570's current scheduling policy: SCHED_OTHER
> pid 20570's current scheduling priority: 0
> pid 20570's current runtime parameter: 2800000
>
> After this patch also, we still get the current setting. Can you give it
> a try with the patch applied? Let me know if I am missing something.
Sorry for the mess. I have finally tried it (sorry for doing it the first time).
Benno's note is that "chrt --other --pid $$" changed behavior. The old version
always just read the current setting if no priority was specified, and now it
alters scheduling and prints nothing. I guess this is the expected behavior now.
I have found that the old version silently ignores the policy option if
priority is not provided, and it always just displays the current setting. This
is ugly, and with your change, it's more ugly :), because it depends on the
specified policy.
chrt --pid $$ # display current setting
chrt --other --pid $$ # alter current setting
chrt --fifo --pid $$ # display current setting (--fifo ignored)
chrt --fifo --pid 10 $$ # alter current setting
I think with --{other,fifo,...} the command line should always be interpreted
as a request to alter the current setting, independently of whether priority is
specified.
chrt --fifo --pid $$
needs to end with the error message "chrt: priority value for the policy
required" rather than display the current setting.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
