![]() | |||||||||||||
Messages in this thread |
On Thu, 2006-08-31 at 12:35 +0200, Martin Ohlin wrote: > Mike Galbraith wrote: > > On Thu, 2006-08-31 at 06:53 +0000, Mike Galbraith wrote: > >> On Thu, 2006-08-31 at 11:07 +1000, Peter Williams wrote: > >> > >>> But your implication here is valid. It is better to fiddle with the > >>> dynamic priorities than with nice as this leaves nice for its primary > >>> purpose of enabling the sysadmin to effect the allocation of CPU > >>> resources based on external considerations. > >> I don't understand. It _is_ the administrator fiddling with nice based > >> on external considerations. It just steadies the administrator's hand. > > > > When extended to groups, I see your point. The admin would lose his > > ability to apportion bandwidth _within_ the group because he's already > > turned his only knob. That is going to be just as much of a problem for > > other methods though, and is just a question of how much complexity you > > want to pay to achieve fine grained control. > > I do not see the problem. Let's say I create a group of three tasks and > give it 50% of the CPU bandwidth (perhaps by using the same nice value > for all the tasks in this group). If I then want to apportion the > bandwidth within the group as you say, then the same thing can be done > by treating them as individual tasks. Multiplex nice? (oh my, dig foxhole) > Maybe I am wrong, but as I see it, if one wants to control on a group > level, then the individual shares within the group are not that > important. If the individual share is important, then it should be > controlled on a per-task level. Please tell me if I am wrong. That's probably right 99% of the time. -Mike - 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: 2006-08-31 12:11 [from the cache] ©2003-2008 | |||||||||||||