SCHED_BATCH and SCHED_BATCH numbering

DISCUSSION Albert Cahalan 4 participants 13 messages Aug 4, 2004 – Aug 5, 2004

Share & tools

Albert Cahalan

author

2004-08-04 19:21 UTC #0 lore raw

Are these going to be numbered consecutively, or might they better be done like the task state? SCHED_FIFO is in fact already treated this way in one place. One might want to test values this way:

if(foo & (SCHED_ISO|SCHED_RR|SCHED_FIFO)) ...

(leaving aside SCHED_OTHER==0, or just translate that single value for the ABI)

I'd like to see these get permenant allocations soon, even if the code doesn't go into the kernel. This is because user-space needs to know the values.

Peter Williams

2004-08-05 01:17 UTC #1 lore raw

Quoted 5 lines · Albert Cahalan

Are these going to be numbered consecutively, or might they better be done like the task state? SCHED_FIFO is in fact already treated this way in one place. One might want to test values this way:

Quoted 8 lines

if(foo & (SCHED_ISO|SCHED_RR|SCHED_FIFO)) ...
(leaving aside SCHED_OTHER==0, or just translate that single value for the ABI)
I'd like to see these get permenant allocations soon, even if the code doesn't go into the kernel. This is because user-space needs to know the values.

Excellent idea. The definition of rt_task() could become:

#define rt_task(p) ((p)->policy & (SCHED_RR|SCHED_FIFO))

instead of the highly dodgy:

#define rt_task(p) ((p)->prio < MAX_RT_PRIO)

Peter

Signature · 4 lines

Peter Williams                                   [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce

Nick Piggin

2004-08-05 01:34 UTC #2 lore raw

Quoted 17 lines · Peter Williams

Quoted 5 lines · Albert Cahalan
Are these going to be numbered consecutively, or might they better be done like the task state? SCHED_FIFO is in fact already treated this way in one place. One might want to test values this way:
Quoted 8 lines
if(foo & (SCHED_ISO|SCHED_RR|SCHED_FIFO)) ...
(leaving aside SCHED_OTHER==0, or just translate that single value for the ABI)
I'd like to see these get permenant allocations soon, even if the code doesn't go into the kernel. This is because user-space needs to know the values.

Quoted 8 lines

Excellent idea. The definition of rt_task() could become:
#define rt_task(p) ((p)->policy & (SCHED_RR|SCHED_FIFO))
instead of the highly dodgy:
#define rt_task(p) ((p)->prio < MAX_RT_PRIO)

Nothing wrong with that, is there?

Peter Williams

2004-08-05 02:09 UTC #3 lore raw

Quoted 20 lines · Nick Piggin

Quoted 18 lines · Peter Williams
Quoted 13 lines · Albert Cahalan
Are these going to be numbered consecutively, or might they better be done like the task state? SCHED_FIFO is in fact already treated this way in one place. One might want to test values this way:
if(foo & (SCHED_ISO|SCHED_RR|SCHED_FIFO)) ...
(leaving aside SCHED_OTHER==0, or just translate that single value for the ABI)
I'd like to see these get permenant allocations soon, even if the code doesn't go into the kernel. This is because user-space needs to know the values.

Quoted 5 lines

Quoted 5 lines
Excellent idea. The definition of rt_task() could become:
#define rt_task(p) ((p)->policy & (SCHED_RR|SCHED_FIFO))
instead of the highly dodgy:

I probably should have said "slightly" instead of "highly" here but I got carried away. :-)

Quoted 5 lines

Quoted 3 lines
#define rt_task(p) ((p)->prio < MAX_RT_PRIO)
Nothing wrong with that, is there?

It's sloppy logic in that "prio" being less than MAX_RT_PRIO is a consequence of the task being real time not the definition of it. At the moment it is a sufficient condition for identifying a task as real time but that may not always be the case. But, the real issue is, what's the point of having a field, "policy", that IS the definitive indicator of the task's scheduling policy if you don't use it? An rt_task() function/macro defined in terms of the policy field with this suggested numbering scheme should always be correct.

At the moment rt_task(p) could be defined as ((p)->policy != SCHED_OTHER) but the addition of SCHED_ISO and SCHED_BATCH would break that. Another option would be (((p)->policy == SCHED_FIFO) || ((p)->policy == SCHED_RR)) but that's a little long winded and (avoiding it) is probably the reason for the current definition. So I stand by my comment that Albert's numbering scheme is an excellent idea.

Peter

Signature · 4 lines

Peter Williams                                   [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce

Nick Piggin

2004-08-05 02:24 UTC #4 lore raw

Quoted 33 lines · Peter Williams

Quoted 21 lines · Nick Piggin
Quoted 19 lines · Peter Williams
Quoted 13 lines · Albert Cahalan
Are these going to be numbered consecutively, or might they better be done like the task state? SCHED_FIFO is in fact already treated this way in one place. One might want to test values this way:
if(foo & (SCHED_ISO|SCHED_RR|SCHED_FIFO)) ...
(leaving aside SCHED_OTHER==0, or just translate that single value for the ABI)
I'd like to see these get permenant allocations soon, even if the code doesn't go into the kernel. This is because user-space needs to know the values.
Quoted 6 lines
Quoted 5 lines
Excellent idea. The definition of rt_task() could become:
#define rt_task(p) ((p)->policy & (SCHED_RR|SCHED_FIFO))
instead of the highly dodgy:
I probably should have said "slightly" instead of "highly" here but I got carried away. :-)
Quoted 1 line
Quoted 1 line

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
#define rt_task(p) ((p)->prio < MAX_RT_PRIO)
Nothing wrong with that, is there?
It's sloppy logic in that "prio" being less than MAX_RT_PRIO is a consequence of the task being real time not the definition of it. At the moment it is a sufficient condition for identifying a task as real time but that may not always be the case.

Actually, p->prio < MAX_RT_PRIO iff rt_task(p). This can't change without horribly breaking stuff.

Quoted 3 lines

But, the real issue is, what's the point of having a field, "policy", that IS the definitive indicator of the task's scheduling policy if you don't use it? An rt_task() function/macro defined in terms of the policy field with this suggested numbering scheme should always be correct.
At the moment rt_task(p) could be defined as ((p)->policy != SCHED_OTHER) but the addition of SCHED_ISO and SCHED_BATCH would break that. Another option would be (((p)->policy == SCHED_FIFO) || ((p)->policy == SCHED_RR)) but that's a little long winded and (avoiding it) is probably the reason for the current definition.

Conversely, p->prio < MAX_RT_PRIO neatly defines a task as being realtime without worrying about what exact policy it is using. However if you add or remove scheduling policies, your p->policy method breaks.

Peter Williams

2004-08-05 03:04 UTC #5 lore raw

Quoted 52 lines · Nick Piggin

Quoted 35 lines · Peter Williams
Quoted 22 lines · Nick Piggin
Quoted 20 lines · Peter Williams
Quoted 13 lines · Albert Cahalan
Are these going to be numbered consecutively, or might they better be done like the task state? SCHED_FIFO is in fact already treated this way in one place. One might want to test values this way:
if(foo & (SCHED_ISO|SCHED_RR|SCHED_FIFO)) ...
(leaving aside SCHED_OTHER==0, or just translate that single value for the ABI)
I'd like to see these get permenant allocations soon, even if the code doesn't go into the kernel. This is because user-space needs to know the values.
Quoted 7 lines
Quoted 5 lines
Excellent idea. The definition of rt_task() could become:
#define rt_task(p) ((p)->policy & (SCHED_RR|SCHED_FIFO))
instead of the highly dodgy:
I probably should have said "slightly" instead of "highly" here but I got carried away. :-)
Quoted 1 line
Quoted 1 line
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
#define rt_task(p) ((p)->prio < MAX_RT_PRIO)
Nothing wrong with that, is there?
It's sloppy logic in that "prio" being less than MAX_RT_PRIO is a consequence of the task being real time not the definition of it. At the moment it is a sufficient condition for identifying a task as real time but that may not always be the case.
Actually, p->prio < MAX_RT_PRIO iff rt_task(p). This can't change without horribly breaking stuff.
Quoted 2 lines
But, the real issue is, what's the point of having a field, "policy", that IS the definitive indicator of the task's scheduling policy if you don't use it? An rt_task() function/macro defined in terms of the policy field with this suggested numbering scheme should always be correct.

Quoted 7 lines

Quoted 1 line
At the moment rt_task(p) could be defined as ((p)->policy != SCHED_OTHER) but the addition of SCHED_ISO and SCHED_BATCH would break that. Another option would be (((p)->policy == SCHED_FIFO) || ((p)->policy == SCHED_RR)) but that's a little long winded and (avoiding it) is probably the reason for the current definition.
Conversely, p->prio < MAX_RT_PRIO neatly defines a task as being realtime without worrying about what exact policy it is using. However if you add or remove scheduling policies, your p->policy method breaks.

Not if Albert's numbering system is used.

Peter

Signature · 4 lines

Peter Williams                                   [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce

Nick Piggin

2004-08-05 03:06 UTC #6 lore raw

Quoted 8 lines · Peter Williams

Quoted 2 lines · Nick Piggin
However if you add or remove scheduling policies, your p->policy method breaks.
Not if Albert's numbering system is used.

What if another realtime policy is added? Or one is removed?

Peter Williams

2004-08-05 03:36 UTC #7 lore raw

Quoted 9 lines · Nick Piggin

Quoted 7 lines · Peter Williams
Quoted 2 lines · Nick Piggin
However if you add or remove scheduling policies, your p->policy method breaks.

Quoted 4 lines

Quoted 2 lines
Not if Albert's numbering system is used.
What if another realtime policy is added? Or one is removed?

What if the "prio" field is removed?

Peter

Signature · 4 lines

Peter Williams                                   [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce

Nick Piggin

2004-08-05 04:41 UTC #8 lore raw

Quoted 12 lines · Peter Williams

Quoted 10 lines · Nick Piggin
Quoted 8 lines · Peter Williams
Quoted 2 lines · Nick Piggin
However if you add or remove scheduling policies, your p->policy method breaks.

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
Not if Albert's numbering system is used.
What if another realtime policy is added? Or one is removed?
What if the "prio" field is removed?

Dunno; the scheduler stops working?

Albert Cahalan

author

2004-08-05 05:02 UTC #9 lore raw

In reply to Nick Piggin

Quoted 4 lines · Nick Piggin

Quoted 2 lines · Peter Williams
Nick Piggin wrote:

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
However if you add or remove scheduling policies, your p->policy method breaks.
Not if Albert's numbering system is used.
What if another realtime policy is added? Or one is removed?

What if, what if...

You're going to have to change the code anyway.
One might toss this into <linux/sched.h> to make
as a nice reminder:

#define SCHEDS_RT (SCHED_RR|SCHED_FIFO)

As it is now, SCHED_FIFO is already used as a
bit flag in one place.

Ingo Molnar

2004-08-05 06:56 UTC #11 lore raw

In reply to Albert Cahalan

Quoted 2 lines · Albert Cahalan

Are these going to be numbered consecutively, or might they better be done like the task state? [...]

this is quite unnecessary at the moment since p->prio < MAX_RT_PRIO is a good enough check - but whenever the way p->prio works is changed it will be easy to introduce a PF_REALTIME flag that is set/cleared in setscheduler(). (instead of playing around with p->policy.)

Ingo

Nick Piggin

2004-08-05 07:09 UTC #10 lore raw

In reply to Albert Cahalan

Quoted 18 lines · Albert Cahalan

Quoted 6 lines · Nick Piggin
Quoted 3 lines · Peter Williams
Nick Piggin wrote:
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
However if you add or remove scheduling policies, your p->policy method breaks.
Not if Albert's numbering system is used.
What if another realtime policy is added? Or one is removed?

Quoted 8 lines

What if, what if...
You're going to have to change the code anyway.
One might toss this into <linux/sched.h> to make
as a nice reminder:
#define SCHEDS_RT (SCHED_RR|SCHED_FIFO)

I'm not saying your renumbering is a bad idea, but making the argument that it would simplify rt_task is bogus.

Quoted 3 lines

As it is now, SCHED_FIFO is already used as a
bit flag in one place.

But it isn't a bit flag, we're just lucky it works. Submit a patch?

Albert Cahalan

author

2004-08-05 12:19 UTC #12 lore raw

In reply to Ingo Molnar

Quoted 9 lines · Ingo Molnar

Quoted 2 lines · Albert Cahalan
Are these going to be numbered consecutively, or might they better be done like the task state? [...]
this is quite unnecessary at the moment since p->prio < MAX_RT_PRIO is a good enough check - but whenever the way p->prio works is changed it will be easy to introduce a PF_REALTIME flag that is set/cleared in setscheduler(). (instead of playing around with p->policy.)

That was one example. I'm guessing that one might want to test for other policy groupings, like these:

SCHED_RR | SCHED_ISO
SCHED_BATCH | SCHED_NORMAL
SCHED_SPORADIC | SCHED_NORMAL
SCHED_EDF | SCHED_FIFO

If that's certainly not going to be useful, even in the future, then of course there's no reason to allocate the values as bits.

In any case, it's a user ABI issue, and I'd like to see what the allocations are going to be. Perhaps I should send in a patch that just allocates a few of these...?