In my own tree I have support for profiling all kernel locks (sx, lockmgr, spin mutexes, and blocking mutexes - not just the current profiling for blocking mutexes) which I'll commit after sun4v has been completely checked in. The biggest offenders on the workloads I've looked at are the lockmgr locks in VFS, user_map (sx) in VM, and sched_lock (spin). Substantial effort will be needed to make FreeBSD scale well past 4 cpus. -Kip On Mon, 9 Oct 2006, Attilio Rao wrote: > 2006/10/9, Kip Macy <kmacy_at_fsmware.com>: > > > > > > 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, > > sleep queue, etc.) to serialize thread updates. I think this is probably > > the best approach. A per proess spin lock would not scale well for large > > multi-threaded apps. > > Yes, this is what I was thinking to. > Maybe sched_lock could be reworked when all the other issues about > SMPng would be closed. > IIRC, somebody was speaking about the starting of a new project which > was related to the analisys and decomposition of the more contentive > locks. > > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Sun Oct 08 2006 - 21:15:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:01 UTC