Re: upreempt_pri

[Lars Heidieker <lars%heidieker.de@localhost>]

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.

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