Re: [PATCH] Time sliced CFQ #2

[Kyle Moffett]

On Dec 06, 2004, at 00:14, Robert Love wrote:
> I think the complication of all of this demonstrates the 
> overcomplexity.
> I think we need to either
>
> 	(1) separate the two values.  we have a scheduling
> 	    priority (distributing the finite resource of
> 	    processor time) and an I/O priority (distributing
> 	    the finite resource of disk bandwidth).
> 	(2) just have a single value.
>
> Personally, I prefer (1).  But (2) is fine.
>
> What we want to do either way is cleanly separate the concepts in the
> kernel.  That way we can decide what we actually expose to user-space.

The reason I proposed my ideas for tying the two values together is 
that I am
concerned about breaking existing code.  I have several binaries to 
which the
source has been lost but I would like to have them continue to properly 
adjust
their priorities internally.  On the other hand, I have other programs 
that I am
currently writing where I would like to be able to have separate IO and 
CPU
priorities.  I believe that we could have two values yet preserve 
backwards
compatibility if we derive the effective IO priority from the sum or 
the provided
IO and CPU priority values, or something along those lines.  That way 
any
program not knowing about the new syscall could just nice() and get both
values adjusted.  If a parent program ran "ioprio()" beforehand to 
adjust the
ioprio with respect to the nice value, then that balance would be 
maintained.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/