Re: Patch to improve mutex collision performance

2002-02-21 Thread Terry Lambert
Matthew Dillon wrote: [ ... ] :How do you reconcile these divergent points of view? These are not divergent points of view. I am saying quite clearly that the ucred code and proc-locking code can be committed in a piecemeal fashion. In fact, good chunk of the proc locking code

Re: Patch to improve mutex collision performance

2002-02-21 Thread David O'Brien
I'm fairly sure JHB does not have a patch to address this but, please, be my guest and check P4. Actually he does. Maybe you should have checked p4 first yourself. Users of Perforce are starting to force the rest of us to learn and use it. That is totally not acceptable for the

Re: Patch to improve mutex collision performance

2002-02-21 Thread Daniel Eischen
On Thu, 21 Feb 2002, Greg Lehey wrote: On Wednesday, 20 February 2002 at 23:48:12 -0500, John Baldwin wrote: What John's patch does is spin while the lock owner is running on another cpu. Spinning while there are no other processes on the run queues as well makes sense but you'll also

Re: Patch to improve mutex collision performance

2002-02-21 Thread John Baldwin
On 21-Feb-02 David O'Brien wrote: I'm fairly sure JHB does not have a patch to address this but, please, be my guest and check P4. Actually he does. Maybe you should have checked p4 first yourself. Users of Perforce are starting to force the rest of us to learn and use it. That

Re: Patch to improve mutex collision performance

2002-02-21 Thread Mike Barcroft
Terry Lambert [EMAIL PROTECTED] writes: Other people's code has dropped by the wayside completely, and been lost; the SACK/TSACK work Luigi did never got integrated and accepted by the project, and LRP code that Peter Druschel and Gaurav Banga did at Rice University, which was originally

Re: Patch to improve mutex collision performance

2002-02-21 Thread Dag-Erling Smorgrav
Matthew Dillon [EMAIL PROTECTED] writes: I'm not interested in using P4. I think it's a mistake. That is, I think it is being severely overused. [...] Frankly, although I use Perforce myself for PAM work, I agree with Matt here. Most of what is going on in the Perforce should be

Re: Patch to improve mutex collision performance

2002-02-21 Thread Garrett Rooney
On Thu, Feb 21, 2002 at 09:14:54PM +0100, Dag-Erling Smorgrav wrote: Matthew Dillon [EMAIL PROTECTED] writes: I'm not interested in using P4. I think it's a mistake. That is, I think it is being severely overused. [...] Frankly, although I use Perforce myself for PAM work, I

Re: Patch to improve mutex collision performance

2002-02-21 Thread Miguel Mendez
On Thu, Feb 21, 2002 at 01:49:09AM -0800, David O'Brien wrote: I'm not a commiter, but here comes my very humble opinion... Users of Perforce are starting to force the rest of us to learn and use it. That is totally not acceptable for the general FreeBSD population. This argument is pretty

Re: Patch to improve mutex collision performance

2002-02-21 Thread Robert Watson
On 21 Feb 2002, Dag-Erling Smorgrav wrote: Matthew Dillon [EMAIL PROTECTED] writes: I'm not interested in using P4. I think it's a mistake. That is, I think it is being severely overused. [...] Frankly, although I use Perforce myself for PAM work, I agree with Matt here.

Re: Patch to improve mutex collision performance

2002-02-21 Thread Dag-Erling Smorgrav
Miguel Mendez [EMAIL PROTECTED] writes: Well, if all developers started using p4, things would be easier and work better in the long term. p4 is lightyears ahead of cvs, and, from what I've read in this thread, developers are not exactly happy with cvs now, as it's limitations have become

Re: Patch to improve mutex collision performance

2002-02-21 Thread Jochem Kossen
On Thu, Feb 21, 2002 at 10:36:39PM +0100, Dag-Erling Smorgrav wrote: Miguel Mendez [EMAIL PROTECTED] writes: Well, if all developers started using p4, things would be easier and work better in the long term. p4 is lightyears ahead of cvs, and, from what I've read in this thread, developers

RE: Patch to improve mutex collision performance

2002-02-21 Thread robert garrett
PROTECTED]] On Behalf Of Jochem Kossen Sent: Thursday, February 21, 2002 4:22 PM To: [EMAIL PROTECTED] Subject: Re: Patch to improve mutex collision performance On Thu, Feb 21, 2002 at 10:36:39PM +0100, Dag-Erling Smorgrav wrote: Miguel Mendez [EMAIL PROTECTED] writes: Well, if all developers started

Re: Patch to improve mutex collision performance

2002-02-21 Thread Dag-Erling Smorgrav
robert garrett [EMAIL PROTECTED] writes: Further enhancing the Elite attitude that is so often proscribed To BSD* developers. I hope you meant ascribed :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the

Re: Patch to improve mutex collision performance

2002-02-21 Thread Terry Lambert
robert garrett wrote: Could someone tell me where documentation concerning the use of perforce and or, how to gain access to is located? http://people.freebsd.org/~peter/p4cookbook.txt Up until very recently I was not aware of it's existence. This would make it very difficult for someone

Re: Patch to improve mutex collision performance

2002-02-21 Thread Terry Lambert
Dag-Erling Smorgrav wrote: robert garrett [EMAIL PROTECTED] writes: Further enhancing the Elite attitude that is so often proscribed To BSD* developers. I hope you meant ascribed :) I think he means FreeBSD developers are not allowed to have that attitude. 8-) 8-). -- Terry To

Re: Patch to improve mutex collision performance

2002-02-21 Thread John Baldwin
On 21-Feb-02 Robert Watson wrote: On 21 Feb 2002, Dag-Erling Smorgrav wrote: Matthew Dillon [EMAIL PROTECTED] writes: I'm not interested in using P4. I think it's a mistake. That is, I think it is being severely overused. [...] Frankly, although I use Perforce myself for

Re: Patch to improve mutex collision performance

2002-02-21 Thread M. Warner Losh
I'd love to see subversion beefed up. It looks like the most promising of the replacements for cvs on the horizon. One thing that it doesn't appear to have, that would be useful to the BSD community, is the ability to cons up a tree from multiple repos easily. If we had that, then we wouldn't

Re: Patch to improve mutex collision performance

2002-02-21 Thread David O'Brien
On Thu, Feb 21, 2002 at 05:00:37PM -0600, robert garrett wrote: Could someone tell me where documentation concerning the use of perforce and or, how to gain access to is located? Up until very recently I was not aware of it's existence. This would make it very difficult for someone new to

RE: Patch to improve mutex collision performance

2002-02-20 Thread John Baldwin
On 18-Feb-02 Matthew Dillon wrote: While testing some Giant removal stuff I noticed that my current system sometimes got into an extremely non-optimal flip-flop situation between two processes contesting Giant on an SMP system which halved the syscall performance in the test.

Re: Patch to improve mutex collision performance

2002-02-20 Thread Greg Lehey
On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote: Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon said words to the effect of; I'm fairly sure JHB does not have a patch to address this but, please, be my guest and check P4. Actually he

Re: RE: Patch to improve mutex collision performance

2002-02-20 Thread Matthew Dillon
This sounds better but why do we need a 'pause' at all? I don't think spinning in this case will have any effect on power consumption. -Matt Matthew Dillon [EMAIL

Re: Patch to improve mutex collision performance

2002-02-20 Thread Matthew Dillon
:On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote: : Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800, : Matthew Dillon said words to the effect of; : I'm fairly sure JHB does not have a patch to address this but, please, : be my guest and check P4. : :

Re: Patch to improve mutex collision performance

2002-02-20 Thread Terry Lambert
Matthew Dillon wrote: I'm not interested in using P4. I think it's a mistake. That is, I think it is being severely overused. At the very least it is preventing me from comitting simple things to -current because as far as I can tell when you add up the junk sitting in P4

Re: Patch to improve mutex collision performance

2002-02-20 Thread Matthew Dillon
:Matthew Dillon wrote: : I'm not interested in using P4. I think it's a mistake. That is, I : think it is being severely overused. At the very least it is preventing : me from comitting simple things to -current because as far as I can tell : when you add up the junk sitting

Re: Patch to improve mutex collision performance

2002-02-20 Thread John Baldwin
On 21-Feb-02 Greg Lehey wrote: On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote: Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon said words to the effect of; I'm fairly sure JHB does not have a patch to address this but, please, be my

Re: RE: Patch to improve mutex collision performance

2002-02-20 Thread John Baldwin
On 21-Feb-02 Matthew Dillon wrote: This sounds better but why do we need a 'pause' at all? I don't think spinning in this case will have any effect on power consumption. The pause is extra stuff mostly needed for the HyperThreading stuff on the Pentium4 and also it helps improve

Re: Patch to improve mutex collision performance

2002-02-20 Thread Greg Lehey
On Wednesday, 20 February 2002 at 23:48:12 -0500, John Baldwin wrote: On 21-Feb-02 Greg Lehey wrote: On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote: Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon said words to the effect of; I'm fairly

Re: Patch to improve mutex collision performance

2002-02-18 Thread David O'Brien
On Mon, Feb 18, 2002 at 11:12:16AM -0800, Matthew Dillon wrote: While testing some Giant removal stuff I noticed that my current system sometimes got into an extremely non-optimal flip-flop situation between two processes contesting Giant on an SMP system which halved the

Re: Patch to improve mutex collision performance

2002-02-18 Thread Matthew Dillon
: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:

Re: Patch to improve mutex collision performance

2002-02-18 Thread Julian Elischer
On Mon, 18 Feb 2002, Matthew Dillon wrote: [...] It turns out that the two processes got into an extremely non-optimal contested/sleep/wakeup situation, even though they do not actually have to sleep on Giant in this situation. The solution is to allow

Re: Patch to improve mutex collision performance

2002-02-18 Thread Bosko Milekic
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

Re: Patch to improve mutex collision performance

2002-02-18 Thread Jake Burkholder
Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon said words to the effect of; :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. I second this request.

Re: Patch to improve mutex collision performance

2002-02-18 Thread Matthew Dillon
: :I can't see any major problem with this but I can't help thinking that :there must be one.. on UP the question is: who is going to :release the lock if no-one is runnable? An interrupt, of course. Wakeups don't happen out of thin air! This is true of 1.x, 2.x, 3.x, 4.x, 5.x, UP,

Re: Patch to improve mutex collision performance

2002-02-18 Thread Matthew Dillon
: 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

Re: Patch to improve mutex collision performance

2002-02-18 Thread Matthew Dillon
:What John's patch does is spin while the lock owner is running on another cpu. :Spinning while there are no other processes on the run queues as well makes sense :but you'll also be doing a lot of acquires and releases of sched_lock. : :The only thing that jumped out at me looking at the patch

Re: Patch to improve mutex collision performance

2002-02-18 Thread David O'Brien
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

Re: Patch to improve mutex collision performance

2002-02-18 Thread David O'Brien
On Mon, Feb 18, 2002 at 12:32:31PM -0800, Matthew Dillon wrote: 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. I really did not think I was bitching about your commit. I just thought

Re: Patch to improve mutex collision performance

2002-02-18 Thread Jake Burkholder
Apparently, On Mon, Feb 18, 2002 at 12:43:18PM -0800, Matthew Dillon said words to the effect of; :What John's patch does is spin while the lock owner is running on another cpu. :Spinning while there are no other processes on the run queues as well makes sense :but you'll also be

Re: Patch to improve mutex collision performance

2002-02-18 Thread Julian Elischer
On Mon, 18 Feb 2002, Matthew Dillon wrote: : :I can't see any major problem with this but I can't help thinking that :there must be one.. on UP the question is: who is going to :release the lock if no-one is runnable? An interrupt, of course. Wakeups don't happen out of thin air!

Re: Patch to improve mutex collision performance

2002-02-18 Thread Matthew Dillon
: :Thanks. : : Ah, critnest... you are right. I should be checking for : critnest 1. : :I think you should just leave it alone, don't check critnest at all. :critnest != 1 is illegal because you can't acquire a sleep lock while :in an enclosing critical section. : :Jake Hmm. It locks

Re: Patch to improve mutex collision performance

2002-02-18 Thread Matthew Dillon
: : :can you detail in more clarity the flip-flopping you were seeing? : : Basically what is happening is that switch/wakeup overhead is being : imposed unnecessarily. There is no need to switch if there is nothing : to switch to, and this also causes the other process to not have