From mboxrd@z Thu Jan 1 00:00:00 1970 From: sri.ram.gmu06@gmail.com (Sri Ram Vemulpali) Date: Fri, 7 Oct 2011 11:40:08 -0400 Subject: Why do processes with higher priority to be allocated more timeslice? In-Reply-To: References: Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org Missed a lot of exciting conversation. Here is the link follow it you will understand the reason of fairness http://www.linuxjournal.com/article/10267 the reason the low-priority task gets less time slice is appropriate to balance between latency and throughput. If high priority task (interactive) needs to preempt the low priority task, in such case, if the system is fully preemptive, it makes sense to give larger time slice for low priority task. If the system is completely preemptive (which is not in normal vanilla kernel), in such case the smaller time slice for low priority task becomes max latency for interactive task to get scheduled. I see in the current kernel code, there is check whether to reschedule the current execution context when returning from interrupt (top half and bottom half), checks "need_resch" field in task_struct. So, I think according to your argument you should able to increase the time slice for low priority task to decrease context switches. You can modify code and test to see what happens. Sri On Tue, Sep 27, 2011 at 11:44 AM, Mulyadi Santosa wrote: > Hi :) > > On Tue, Sep 27, 2011 at 20:06, Parmenides wrote: >> Initially, I think that the scheduler should enlarge the timeslices of >> CPU-bound processes to improve throughput. > > True.... :) > >>But, now I have realized >> that the two goals of schedulers, namely shorter latency and higher >> throughput, can not be achieved at the same time. Linux scheduler may >> prefer to the former. Thanks! :-) >> > > I always think that the problem is, let N is the number of the jobs, > and M is the number of processor, whenever N>M, scheduler could never > achieve ideal situation (both lower latency and higher throughput). If > at least N=M, now that's we're talkin' :) > > Another problem is actually Linux kernel is not real time kernel. It's > not really a big problem actually in most cases, but in some cases it > might e.g sound processing. Unbounded latency in non real time kernel > is a big no no in such situations. > > Just my 2 cents thought :) > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Regards, Sri.