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>