Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 9 Oct 2006 01:03:39 +0200
From:      "Attilio Rao" <attilio@freebsd.org>
To:        "Kip Macy" <kmacy@fsmware.com>,  "John-Mark Gurney" <gurney_j@resnet.uoregon.edu>,  "David Xu" <davidxu@freebsd.org>, freebsd-current@freebsd.org,  "Ivan Voras" <ivoras@fer.hr>
Subject:   Re: [PATCH] MAXCPU alterable in kernel config - needs testers
Message-ID:  <3bbf2fe10610081603r1161ac38h4b679e452b6849f6@mail.gmail.com>
In-Reply-To: <20061008155817.G29803@demos.bsdclusters.com>
References:  <2fd864e0610080423q7ba6bdeal656a223e662a5d@mail.gmail.com> <20061008135031.G83537@demos.bsdclusters.com> <4529667D.8070108@fer.hr> <200610090634.31297.davidxu@freebsd.org> <20061008225150.GK793@funkthat.com> <3bbf2fe10610081555r67265368sf7f12edbf35bff0d@mail.gmail.com> <20061008155817.G29803@demos.bsdclusters.com>

next in thread | previous in thread | raw e-mail | index | archive | help
2006/10/9, Kip Macy <kmacy@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10610081603r1161ac38h4b679e452b6849f6>