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