Kip Macy wrote this message on Sun, Oct 08, 2006 at 15:59 -0700: > > > > How would you see a sched_lock decomposition (and, if it is possible, > > how many locks it could be decomposed in?) > > Rather than having a per thread lock, Solaris uses the lock for the > current container that a thread is associated with (cpu, run queue, Wouldn't having a single run queue lock still serialize the cpu's when getting a thread to run? Don't we really need a per cpu run queue, and then have a scheduler that puts threads on the cpu's run queues? we probably should move some of the stats (LA) to pcpu data structure and desolving sched_lock from thread priority updates... This would mean sched_lock would need to be aquired less often, closer to quantum (which is ~100ms now) instead of each hz... There is probably work to be done to push the locks down around thread, proc and kse/ksg... It looks like a lot of the work done each HZ could be a lot more local than it currently is... It's probably not so much scheduling over head that is killing sun4v but the stats gathering.. Though I have very little knowlege about how scheduling works, so I am probably incorrect.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."Received on Sun Oct 08 2006 - 22:22:15 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:01 UTC