Re: Massive performance loss from OS::sleep hack

On Tue, 18 Sep 2007, Kurt Miller wrote:

Hi Daniel,

Daniel Eischen wrote:
On Tue, 18 Sep 2007, Kurt Miller wrote:

David Xu confirmed for me that pthread_yield() does give some
time to lower priority threads on 7.0 using thr. Attached and inline
are two patches for the 1.5 port that is how I suggest the issue be
addressed.

I don't think you should rely on pthread_yield() doing that,
it is dependent on the scheduler, and if you are running
in SCHED_FIFO/SCHED_RR, it won't work with libthr either.
Currently, you can only run in SCHED_FIFO or SCHED_RR as
root using libthr, but that hopefully won't always be
true.

Shoot I forgot to mention a few things in my last email...
The c test program I resurrected from 18 months ago had

pthread_attr_setschedpolicy(&attr, SCHED_FIFO);

in it. The jdk doesn't set the schedpolicy it uses the
default one. That line was left over from my testing
different policies under kse to see if I could work-
around the problem. Since the jdk doesn't set the policy,
I believe we don't need to be concerned with SCHED_FIFO
and SCHED_RR.

libkse and libc_r default to SCHED_RR (SCHED_OTHER=SCHED_RR).

I think the way that will always work is to lower the
priority and raise it back again after the yield, when
using thread priorities. This should work for libthr,
libc_r, and libkse under all versions of the OS.

On the surface this sounded promising, but I can envision
at least one case where temporarily lowering a thread
priority will not work very well. Take three threads A, B &
C each with different priorities: A highest, C lowest. Let's
say A is in a busy loop calling Thread.Yield(). B is in a busy
loop also calling Thread.Yield(). C is doing something that
needs some time slices every so often. A calls Thread.Yield(),
lowers priority to C's level, B gets some time next, it calls
Thread.Yield(), lowers priority to C's level. A, B, C are all
at equal level now. Perhaps C will get some time first, or B,
or A. Suppose the order is C first, B next. A will only get
a time slice if B continues to call yield and by chance the
system schedules A before B. The behavior becomes
non-deterministic. The worst case is A is starved.

No, if the threads are at equal priority, they will always
run. The system, either the userland scheduler or the kernel,
will ensure the threads get scheduled equally. For the
kernel scheduler, "equally" depends on their resource usage.

I would just totally ignore setting thread priorities
unless the UseThreadPriority knob is set. The kernel
scheduler (for libthr) doesn't seem to care what a thread's
priority is anyways unless it is in the real-time class.
That way, all threads will be at the default priority
by default ;-)

--
DE
_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • [RFC][PATCH] O(1) Entitlement Based Scheduler
    ... This patch is a modification of the Oscheduler that introduces ... _entitlement_ to CPU resources that is determined by the number of _shares_ ... This patch provides both soft and hard CPU usage rate caps per ... one getting the most can be given a better priority, ...
    (Linux-Kernel)
  • Re: Renice X for cpu schedulers
    ... (That's all that any of these dynamic priority heuristics ... really seem to do -- weight the scheduler towards switching to ... the design _intent_; but I think it's fairly accurate in terms of the ... non-threaded design of the X server makes it ...
    (Linux-Kernel)
  • [patch] 2.6.21-rc4 nicksched v32
    ... Considering the recent attention on CPU schedulers, ... but it is yet another scheduler. ... struct pipe_inode_info; ... 'User priority' is the nice value converted to something we ...
    (Linux-Kernel)
  • [patch 1/] timers: tsc using for cpu scheduling
    ... uses jiffies_64 for process priority calculation instead of Time Stamp ... Clock (TSC). ... process which provoke to memory threshing and bad cpu and cash using has ... But for scheduler purposes the value of work ...
    (Linux-Kernel)
  • [PATCH] Staircase cpu scheduler 2.6.8-rc2-mm1
    ... This is a rewrite of the scheduler policy for 2.6, ... - Interactive by design rather than have complicated interactivity ... - Making renicing processes actually matter for CPU distribution ... A descending foreground-background single runqueue per cpu priority ...
    (Linux-Kernel)