From owner-freebsd-current Wed Feb 20 19:56: 0 2002 Delivered-To: freebsd-current@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 5BF2337B402; Wed, 20 Feb 2002 19:55:57 -0800 (PST) Received: from pool0050.cvx22-bradley.dialup.earthlink.net ([209.179.198.50] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16dkKp-00031G-00; Wed, 20 Feb 2002 19:55:56 -0800 Message-ID: <3C746FC1.897E759C@mindspring.com> Date: Wed, 20 Feb 2002 19:55:45 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Greg Lehey , Jake Burkholder , 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> <20020218153807.E96115@locore.ca> <20020221111915.N65817@wantadilla.lemis.com> <200202210146.g1L1kqg91511@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 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 it touches almost every file > in the kernel tree. Everything I've tried to work on has some hack > sitting in P4 somewhere that somebody hasn't committed. By the same token, you have also stated: ] Well... try again. If something ought to be compatible in a piecemeal ] commit and isn't, then something unexpected happened and you need to ] find out what it was. Doing a full-on commit for something like the ] proc lock patch is far too dangerous. It's just too large a patch set ] and we know from experience (cam, softupdates, etc...) that having a ] small handful of people testing a large private patch is not going to ] find all the bugs. How do you reconcile these divergent points of view? > I would like to see John commit his ucred stuff with Giant > instrumentation. If he doesn't want to do it then I would like him > to give me permission to do it from my tree now. I see no reason why > we should have to wait another X days or weeks to see this stuff in > the main tree. It just makes no sense to me. What large scale changes are "OK", and what large scale changes are "too dangerous"? Do you have a set of rules, that would let us look at a patch set and instantly decide which of these two categories the code fell into? I'm not trying to be a jerk, but not everything can be broken down into 1 line commits, and not everything can be broken down into 8 line commits, or 64 line commits, or 512 line commits, etc. (if you'll forgive my proof by induction). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message