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
