Re: [PATCH] Time sliced CFQ #2

[Jeff Sipek <jeffpc@optonline.net>]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]