Messages in this thread | | | Date | Sun, 05 Dec 2004 21:23:38 -0500 | From | Jeff Sipek <> | Subject | Re: [PATCH] Time sliced CFQ #2 |
| |
On Mon, Dec 06, 2004 at 12:59:43PM +1100, Con Kolivas wrote: > Jeff Sipek wrote: > >I started working on the rudimentary io prio code, and it got me > >thinking... > >Why use the cpu scheduler priorities? Wouldn't it make more sense to add > >io_prio to task_struct? This way you can have a process which you know > >needs > >a lot of CPU but not as much io, or the other way around. > > That is the design the Jens' original ioprio code used which we used in > -ck for quite a while. What myself and -ck users found, though, was that > being tied to cpu 'nice' meant that most tasks behaved pretty much as > we'd expect based on one sys call. > > I think what is ideal is to have both.
Agreed.
> First the ioprio should be set to > what the cpu 'nice' level is as a sort of global "this is the priority > of this task" setting. Then it should also support changing of this > priority with a different call separate from the cpu nice. That way we > can take into account access privileges of the caller making it > impossible to set a high ioprio if the task itself is heavily niced by a > superuser and so on.
This sounds very reasonable. How would a situation like this one get handeled:
nice = x io_prio = y
where x!=y
then, user changes nice. Does the nice level change alone? If so, providing some "reset to nice==io_prio" capability would make sense, no?
Jeff. [unhandled content-type:application/pgp-signature] | |