Date: Mon, 18 Feb 2002 12:32:31 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: "David O'Brien" <obrien@FreeBSD.ORG>, current@FreeBSD.ORG Subject: Re: Patch to improve mutex collision performance Message-ID: <200202182032.g1IKWVS36193@apollo.backplane.com> References: <200202181912.g1IJCGK32122@apollo.backplane.com> <20020218114326.A98974@dragon.nuxi.com> <200202181951.g1IJpip33604@apollo.backplane.com> <20020218150355.A21615@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: 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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202182032.g1IKWVS36193>