> Does this code make sense ? It's from kswapd(), mm/vmscan.c (2.1.* and 2.0.*)
Nope, it hardly makes sense :-) The current->priority
setting is a (harmless) leftover from the days where
we didn't have SCHED_FIFO...
> /* Give kswapd a realtime priority. */
> current->policy = SCHED_FIFO;
> current->priority = 32;
>
> Looking at schedule() and goodness() in kernel/sched.c, the scheduling
> algorithm does not consider 'counter' and 'priority' if the
> 'policy' of the task is different from SCHED_OTHER. Indeed in goodness()
>
> --- vmscan.c.orig Wed Jun 24 18:43:04 1998
> +++ vmscan.c Wed Jun 24 18:43:19 1998
> @@ -532,7 +532,7 @@
>
> /* Give kswapd a realtime priority. */
> current->policy = SCHED_FIFO;
> - current->priority = 32; /* Fixme --- we need to standardise our
> + current->rt_priority = 32; /* Fixme --- we need to standardise our
> namings for POSIX.4 realtime scheduling
> priorities. */
It might be better to change the value to 50. This way we
can have 'soft' realtime tasks with a priority below
kswapd's and 'hard' realtime tasks with a priority higher
than kswapd's.
Of course, THIS NEEDS TO BE DOCUMENTED EVERYWHERE !!!
This is because people doing realtime work expect their
realtime task to be realtime, kswapd or no kswapd...
This is also the reason why people like Benjamin or me
haven't 'fixed' this minor nitpick either, there might
be programs out there depending on hard realtime which
have a somewhat low RT priority set...
The way it is now, kswapd has a priority of 1000 in
goodness() (sched.c) and all other realtime tasks have
a higher priority. This might be good, but it might also
be bad...
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu