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 Xu
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
