lkml.org 
[lkml]   [2002]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] 2.5: MAX_PRIO cleanup
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.072 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site