On Thu, Feb 21, 2002 at 10:00:29PM -0700, M. Warner Losh wrote:
> 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
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
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 n
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 Perf
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
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 some
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"
CTED]
[mailto:[EMAIL 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
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, de
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 becom
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
>
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 prett
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 wo
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
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
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
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
>> 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 th
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
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;
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 impro
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,
>>>
: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 sittin
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 P
: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.
:>
:
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
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.
>
> Actua
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 te
:>
:> :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
:
: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 loc
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 thi
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 do
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
th
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
: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 is
: 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
:
: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, a
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.
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 e
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 _mtx_lock_s
: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:
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
> s
42 matches
Mail list logo
