Messages in this thread | | | Subject | Re: [PATCH] 2.5: MAX_PRIO cleanup | From | Robert Love <> | Date | 23 Apr 2002 12:53:40 -0400 |
| |
On Tue, 2002-04-23 at 03:53, Ingo Molnar wrote:
> i agree that this area needs cleaning up, but i dont agree with all > aspects of your patch. I intentionally left the user-space API side > separate, MAX_RT can in fact be higher than 100 (without changing the > user-space API), the only rule is that it must not be smaller. We in fact > had such a situation once. It's a perfectly valid goal to have 'super > high prio' kernel-space threads in the future that have in fact some > priority that cannot be reached by user-space threads. > > so i've re-done a variation of your patch, which defines USER_MAX_RT_PRIO, > so the user-space API can still stay separate from the kernel-internal > representation.
This is better. I did not want to add another define or a new policy (i.e. user != kernel maximum priority) but doing so is valid. Actually, I think there are a lot of kernel threads where we probably want to set a priority above the max user-space priority.
There are circumstances in user programming where we want a larger maximum RT priority, too. In serious RT programming it wouldn't be uncommon to see 100-1000 priority levels. I think having such a wide range is partly to make programming easier (i.e. a lame crutch) but it does help to more readily layer real-time tasks.
Now the hard part is abstracting sched_find_first_set for an arbitrary MAX_RT_PRIO.
> i've also done some other changes: > > > /* > > - * Priority of a process goes from 0 to 139. The 0-99 > > - * priority range is allocated to RT tasks, the 100-139 > > - * range is for SCHED_OTHER tasks. Priority values are > > - * inverted: lower p->prio value means higher priority. > > + * Priority of a process goes from 0 to MAX_PRIO-1. The > > + * 0 to MAX_RT_PRIO-1 priority range is allocated to RT tasks, > > + * the MAX_RT_PRIO to MAX_PRIO range is for SCHED_OTHER tasks. > > + * Priority values are inverted: lower p->prio value means higher > > + * priority. > > this i dont agree with either. The point of comments is easy > understanding, so i intentionally kept the 'hard' constants and i'm > updating them constantly - it's much easier to understand how things > happen if it does not happen via a define. The code itself i agree should > stay abstract, but the comments should stay as humanly readable as > possible.
Whatever you prefer...
> (the set|get_affinity comment fixes i kept, plus the runqueue > double-lock/unlock comments as well, see the attached patch.)
Great, thank you.
Linus, Ingo's patch is fine by me. Apply?
Robert Love
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |