[PATCH] MAXCPU alterable in kernel config - needs testers

[Kip Macy]

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"
>