On 2012/11/03 02:26, Jeff Roberson wrote: > I have a small patch to the ULE scheduler that makes a fairly large > change to the way timeshare threads are handled. > > http://people.freebsd.org/~jeff/schedslice.diff > > Previously ULE used a fixed slice size for all timeshare threads. Now > it scales the slice size down based on load. This should reduce latency > for timeshare threads as load increases. It is important to note that > this does not impact interactive threads. But when a thread transitions > to interactive from timeshare it should see some improvement. This > happens when something like Xorg chews up a lot of CPU. > > If anyone has perf tests they'd like to run please report back. I have > done a handful of validation. > > Thanks, > Jeff Another problem I remembered is that a thread on runqueue may be starved because ULE treats a sleeping thread and a thread waiting on runqueue differently. If a thread has slept for a while, after it is woken up, its priority is boosted, but for a thread on runqueue, its priority will never be boosted. In essential, they should be same becase both of them are waiting for cpu. If I am a thread, I'd like to wait on sleep queue rather than on runqueue, since in former case, I will get bonus, while in later case, I'll get nothing. Under heavy load, there are many runnable threads, this unfair can cause a very low priority thread on runqueue to be starved. 4BSD seems not suffer from this problem, because it also decay cpu time of thread on runqueue. I think ULE needs some anti-starvation code to give thread a shot if it is waiting on runqueue too long time. Regards, David XuReceived on Mon Nov 05 2012 - 01:40:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:31 UTC