Why do processes with higher priority to be allocated more timeslice?

[Sri Ram Vemulpali]

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
<mulyadi.santosa at gmail.com> wrote:
> Hi :)
>
> On Tue, Sep 27, 2011 at 20:06, Parmenides <mobile.parmenides at gmail.com> 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.