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 ]
