Re: upreempt_pri

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> On 01/10/2012 03:30 AM, YAMAMOTO Takashi wrote:
>> hi,
>> 
>>> Hi,
>>> 
>>> I would like to change upreempt_pri to default to 0 as this makes
>>>  wakeups where the interrupted cpu schedules a thread on another
>>> cpu behave like as if it where scheduled on the interrupted cpu.
>>> 
>>> For the case that  the to be scheduled on cpu is the interrupted
>>> one, the behavior is like having upreempt_pri set to 0, as
>>> rescheduling happens on return too usermode while in the cross
>>> cpu case this might be delayed until the next timer interrupt.
>>> 
>>> This change makes some sluggishness regarding X to go a way. 
>>> (Solaris defaults to 0 here as well, I think the only reason to
>>> set it higher is on very big SMP machines where throughput is
>>> more important then latency)
>>> 
>>> Lars
>> 
>> i'm not sure how it can make much differences given that l_kpribase
>> is normally PRI_KERNEL.
>> 
> 
> isn't eprio in that case a user space priority if the thread was
> preempted during user space execution?

on a preemption, sched_enqueue is called with swtch=true and
sched_upreempt_pri is not used.
after that, if the lwp is moved to another cpu, sched_upreempt_pri
might matter.  is it the case you are talking about?

YAMAMOTO Takashi

> 
>> can you explain a little more? or, even better, can you try to
>> create a smaller test program to demonstrate the sluggishness?
>> 
>> 
> 
> The rational behind this is that the highest priority thread should
> run which is not always the case if user space preemption had happened.
> On my machine the behavior is quite obvious with compiles running in
> the background and moving windows in X.
> 
> Lars
> 
> 
> 
> -- 
> ------------------------------------
> 
> Mystische Erkldrungen:
> Die mystischen Erkldrungen gelten f|r tief;
> die Wahrheit ist, dass sie noch nicht einmal oberfldchlich sind.
> 
>    -- Friedrich Nietzsche
>    [ Die Frvhliche Wissenschaft Buch 3, 126 ]