From owner-freebsd-current Mon Feb 18 12:33: 0 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4869037B417; Mon, 18 Feb 2002 12:32:33 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1IKWVS36193; Mon, 18 Feb 2002 12:32:31 -0800 (PST) (envelope-from dillon) Date: Mon, 18 Feb 2002 12:32:31 -0800 (PST) From: Matthew Dillon Message-Id: <200202182032.g1IKWVS36193@apollo.backplane.com> To: Bosko Milekic Cc: "David O'Brien" , current@FreeBSD.ORG Subject: Re: Patch to improve mutex collision performance References: <200202181912.g1IJCGK32122@apollo.backplane.com> <20020218114326.A98974@dragon.nuxi.com> <200202181951.g1IJpip33604@apollo.backplane.com> <20020218150355.A21615@unixdaemons.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : I've looked at it and I think it's OK. There are a few minor things I :could think of, but they are only related to the context-borrowing :interrupt stuff I'm working on in parallel (notably, when it goes in, :I'll modify the "if ()" statement in there to add a check and only :perform the lazy spin if we're not borrowing context). Yah, I saw the not-yet code just below it. At worst we would simply not optimize for the borrowing case, or move the optimization to just below it (or move the interrupt borrowing code to above it, i.e. before we mess with the CONTESTED bit stuff, which may be better). : This only to say that I'm glad that you at least posted it for review, :as it allowed me to make a quick note of this. : The only other issue has to do with you getting pre-empted by, say, an :interrupt after dropping sched_lock and then, should the lock you're :trying to get become contested while the handler is running, have :relatively weak priority on it after you iret and continue iterating. :However, the odds of this happening are not only weak but this small :loss of priority already exists in the locking code anyway (think of :when we're trying to get a lock and get pre-empted right after failing :to get it but before grabbing sched_lock and putting ourselves to :sleep). So, in effect, it's a non-issue. : :-- :Bosko Milekic The simple stuff I like to just commit... like instrumenting something like getuid() which makes no actual change to the way Giant operates in the system unless you play with the sysctl. The more complex stuff I throw up as a notice of intent or to support test results. The really complex stuff I get an actual review for. --- People like to bitch and moan about my commits but, frankly, there isn't much to really bitch and moan about if you actually look at the commits. None of this stuff is not rocket science. -current has been broken half a dozen times in the last month and not a single one of those breakages has been due to me, so people should bitch and moan and someone else. I suppose I am just a convenient punching bag. (And, as a side note to the bozos on IRC that complained about my kern.giant.ucred commit I will note that I was the person who CREATED the instrumented giant code in the first place. If code could be said to be owned by anyone that code could be said to be owned by me. That code exists precisely to allow incremental Giant pushdown commits to -current without blowing up other developers, which is precisely what I am doing). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message