Date: Mon, 18 Feb 2002 15:03:55 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: "David O'Brien" <obrien@FreeBSD.ORG>, current@FreeBSD.ORG Subject: Re: Patch to improve mutex collision performance Message-ID: <20020218150355.A21615@unixdaemons.com> In-Reply-To: <200202181951.g1IJpip33604@apollo.backplane.com>; from dillon@apollo.backplane.com on Mon, Feb 18, 2002 at 11:51:44AM -0800 References: <200202181912.g1IJCGK32122@apollo.backplane.com> <20020218114326.A98974@dragon.nuxi.com> <200202181951.g1IJpip33604@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon wrote: > > :I request that you give say a 3 day review period for this. > :I know JHB still has limited email access (no DSL yet). > :This may be something he should review. > > Sigh. Are you intending to ask me to have JHB review every single change > I make to -current? Because if you are the answer is: "Are you out of > your mind?". > > I'm fairly sure JHB does not have a patch to address this but, please, > be my guest and check P4. 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). 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. > -Matt > Matthew Dillon > <dillon@backplane.com> -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org 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?20020218150355.A21615>