Re: upreempt_pri

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

hi,

> hi,
> 
> On 02/21/2012 08:11 AM, YAMAMOTO Takashi wrote:
>> 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?
>> 
> 
> yes, that is the case I have in mind, the behavior if the process is
> schedule on another cpu differs from the local one, it's dispatch
> might be delayed braking the contract that the process/lwp with
> highest priority should run for user preemption slightly.

given that netbsd-6 has been branched, it's probably a good time to
make the change and see.

YAMAMOTO Takashi

> 
> Lars
> 
>> 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