:I agree that the use of cpu_critical_enter/exit could use cleaning up.
:Can you give an example of where critical_enter is used improperly?
:You mean in fork_exit? Your changes to cpu_switch solve that problem
:with critical_exit almost unchanged. The savecrit stuff should really
:just be
On Thu, 7 Mar 2002, Jake Burkholder wrote:
Apparently, On Thu, Mar 07, 2002 at 05:21:21PM -0500,
Robert Watson said words to the effect of;
The primary objections I've seen from Jake, and he posted them as part of
the earlier thread prior to the commit, was that the API changes
On 08-Mar-02 Matthew Dillon wrote:
:I agree that the use of cpu_critical_enter/exit could use cleaning up.
:Can you give an example of where critical_enter is used improperly?
:You mean in fork_exit? Your changes to cpu_switch solve that problem
:with critical_exit almost unchanged. The
Apparently, On Fri, Mar 08, 2002 at 01:23:01AM -0800,
Matthew Dillon said words to the effect of;
:I agree that the use of cpu_critical_enter/exit could use cleaning up.
:Can you give an example of where critical_enter is used improperly?
:You mean in fork_exit? Your changes to
:On 08-Mar-02 Matthew Dillon wrote:
:
::I agree that the use of cpu_critical_enter/exit could use cleaning up.
::Can you give an example of where critical_enter is used improperly?
::You mean in fork_exit? Your changes to cpu_switch solve that problem
::with critical_exit almost unchanged.
:The reason is that if they are in MI code they automatically apply to all
:platforms and can't get out sync. When they are modified to handle preemption
:the freebsd kernel will be fully preemptive. Not, it works on i386 and its
:believed to work on alpha and powerpc is not preemptive at all
In message: [EMAIL PROTECTED]
Matthew Dillon [EMAIL PROTECTED] writes:
: We have very different development models, and different priorities.
: I'm not sure why you are attempting to impose your development model
: and priorities on me. This is the work I want to do.
The API is intended for the stage-2 commit. The stage-1 commit
is intended to do all the 'hard stuff' in as straightforward
a manner as possible. The sysctl / option you talk about here
existed in my patch set 2 and a half weeks ago.
The API and getting it right is more
Can someone please end this nightmare?
If you've reviewed the patch and found substantive reason to contest it
then speak now else the patch should be commited today so that forward
progress can continue. I mean, cut the crap and state the facts you see
about the code or sit in silence while
Trim your cc's.
I'm sorry, but simply not liking the idea of someone else doing a
particular optimization now verses later is not a good enough reason
to require that 40+ hours worth of work be thrown away when that
other person has stated, repeatedly, that he will support
On Thu, 7 Mar 2002, Michael Smith wrote:
Trim your cc's.
I'm sorry, but simply not liking the idea of someone else doing a
particular optimization now verses later is not a good enough reason
to require that 40+ hours worth of work be thrown away when that
other
If memory serves me right, Bruce A. Mah wrote:
[snip]
Disregard. I hit the wrong button in my MUA. Sorry for the spammage.
Bruce.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
: those reviews object on a purely subjective manner.
:
:
: I think this is premature
:
: I don't consider that to be a technical review? do you?
If that's what he said, no. However, that's not all that he said.
Also, Jake had several objections from a sparc64 perspective that
weren't
:The API is intended for the stage-2 commit. The stage-1 commit
:is intended to do all the 'hard stuff' in as straightforward
:a manner as possible. The sysctl / option you talk about here
:existed in my patch set 2 and a half weeks ago.
:
:The API and getting it right is more
Apparently, On Thu, Mar 07, 2002 at 05:21:21PM -0500,
Robert Watson said words to the effect of;
On Thu, 7 Mar 2002, Warner Losh wrote:
In message [EMAIL PROTECTED] Julian
Elischer writes:
:
:
: On Thu, 7 Mar 2002, Justin T. Gibbs wrote:
:
: Then do the right
:I didn't have to read the patch to know that there were concerns and
:on-going discussion about the API. In this instance, the issues are
:not large and can be remedied quickly - all the more reason for the
:discussion to take place before the commit.
Again, bullshit. You should have read
:
:You came to the conclusion that only *your decision* on what was
:an appropriate proceedure was the one that mattered. That's not
:the way this project works. You can't act unilaterally. When people
:ask you to hold off (and they even asked politely!) so discussion
:can take place, that is
On Thu, 7 Mar 2002, Justin T. Gibbs wrote:
The only way it will get delayed that long is if you spend all of your
time stomping up and down, writing in all caps, and tell the rest of
us that we have to follow the proceedures you think are appropriate.
That's not how colaboration works.
No, Core has just said that he doesn't because he can over-rule any change
in the kernel. And there is no requirement for him to justify it.
That is definately *NOT* what core has said. Please go re-read our
announcement of the SMPng tech lead appointment. We specifically indicate
that the
On Thu, 7 Mar 2002, David Greenman wrote:
No, Core has just said that he doesn't because he can over-rule any change
in the kernel. And there is no requirement for him to justify it.
That is definately *NOT* what core has said. Please go re-read our
announcement of the SMPng tech lead
:
:You came to the conclusion that only *your decision* on what was
:an appropriate proceedure was the one that mattered. That's not
:the way this project works. You can't act unilaterally. When people
:ask you to hold off (and they even asked politely!) so discussion
:can take place, that is
On Thu, 7 Mar 2002, Justin T. Gibbs wrote:
The only way it will get delayed that long is if you spend all of your
time stomping up and down, writing in all caps, and tell the rest of
us that we have to follow the proceedures you think are appropriate.
That's not how colaboration works.
If memory serves me right, Justin T. Gibbs wrote:
:
:You came to the conclusion that only *your decision* on what was
:an appropriate proceedure was the one that mattered. That's not
:the way this project works. You can't act unilaterally. When people
:ask you to hold off (and they even
:Yes. What I would like and what I mentioned before is for this to be
:hidden behind cpu_critical_enter/exit. Specifically, cpu_critical_enter
:would be a null macro for i386, which would turn critical_enter into
:just an increment, as Matt wanted. cpu_critical_exit would do all the
:magic of
At 7:04 PM -0800 3/7/02, Matthew Dillon wrote:
:Bruce also had some comments which were shrugged off, I thought they
:were important. Specifically, please do not make unnecessary changes
:to the assembler code. Macros do not need to be defined before they
:are used, I believe this was the
On Thu, 7 Mar 2002, Justin T. Gibbs wrote:
Then do the right things so it will.
Unfortunatly that has been proven to not work.
after reverting the change and silently waiting for a week
1/ no person bothered to review it.
2/ people assumed the patch had gone away.
To Unsubscribe: send
In message [EMAIL PROTECTED] Julian
Elischer writes:
:
:
: On Thu, 7 Mar 2002, Justin T. Gibbs wrote:
:
: Then do the right things so it will.
:
: Unfortunatly that has been proven to not work.
:
: after reverting the change and silently waiting for a week
: 1/ no person bothered to
those reviews object on a purely subjective manner.
I think this is premature
I don't consider that to be a technical review? do you?
they do not even comment on the bug-fixing aspect of the patch.
On Thu, 7 Mar 2002, Warner Losh wrote:
In message [EMAIL PROTECTED] Julian
Elischer writes:
On 07-Mar-02 Matthew Dillon wrote:
:Search for paper John Baldwin and find link 6:
:
:http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=199282+204026+/usr/local/www/db/
:text/2002/freebsd-arch/20020303.freebsd-arch
:
:The actual paper is at:
:
On Thu, 7 Mar 2002, Warner Losh wrote:
In message [EMAIL PROTECTED] Julian
Elischer writes:
:
:
: On Thu, 7 Mar 2002, Justin T. Gibbs wrote:
:
: Then do the right things so it will.
:
: Unfortunatly that has been proven to not work.
:
: after reverting the change and silently
:
:In otherwords. You acted unilaterally. You seem to be making my
:arguments for me. Again. Thanks!
No, I am not acting unilaterally, but neither do I feel it is appropriate
to be told to wait indefinitely (and I am STILL waiting by the way!).
When I commit something it isn't set
:: after reverting the change and silently waiting for a week
:: 1/ no person bothered to review it.
:: 2/ people assumed the patch had gone away.
:
:Ummm, There are reviews in the archives that object to the API as it
:relates to optimization and those objections haven't been sanely
:answered
:You seemed to have missed the entire part where we handle deferred preemptions
:in MI code in critical_exit(). The critical_enter/exit stuff really exists to
:support the preemption code and to get rid of the various FOO_NOSWITCH flags.
:I think it is ok to remove the linkage between
:The primary objections I've seen from Jake, and he posted them as part of
:the earlier thread prior to the commit, was that the API changes proposed
:by Matt don't make sense for the sparc64 implementation, uni-processor or
:multi-processor, and that while these changes might be appropriate for
On Thu, Mar 07, 2002 at 02:43:36PM -0700, Warner Losh wrote:
In message [EMAIL PROTECTED] Julian
Elischer writes:
:
:
: On Thu, 7 Mar 2002, Justin T. Gibbs wrote:
:
: Then do the right things so it will.
:
: Unfortunatly that has been proven to not work.
:
: after reverting the
On Tuesday, 5 March 2002 at 9:43:29 -0800, Matthew Dillon wrote:
phk wrote:
you have a right to bully the only person who have consistently
chugged away at the SMPng project when practically everybody else
(you included) defected.
This is an extreme misrepresentation of the facts. I
On Thursday, 7 March 2002 at 14:30:47 -0800, Matthew Dillon wrote:
after reverting the change and silently waiting for a week
1/ no person bothered to review it.
2/ people assumed the patch had gone away.
Ummm, There are reviews in the archives that object to the API as it
relates to
On Thursday, 7 March 2002 at 13:19:05 -0800, Julian Elischer wrote:
On Thu, 7 Mar 2002, David Greenman wrote:
No, Core has just said that he doesn't because he can over-rule any change
in the kernel. And there is no requirement for him to justify it.
That is definately *NOT* what core
On Thursday, 7 March 2002 at 13:19:05 -0800, Julian Elischer wrote:
On Thu, 7 Mar 2002, David Greenman wrote:
No, Core has just said that he doesn't because he can over-rule any change
in the kernel. And there is no requirement for him to justify it.
That is definately *NOT* what core
On Thursday, 7 March 2002 at 16:43:40 -0800, David Greenman wrote:
On Thursday, 7 March 2002 at 13:19:05 -0800, Julian Elischer wrote:
On Thu, 7 Mar 2002, David Greenman wrote:
No, Core has just said that he doesn't because he can over-rule any change
in the kernel. And there is no
:Perhaps that part of the update could be considered cosmetic, and
:thus be done as a separate update -- just so people can tell which
:lines are cosmetic changes and which ones are substantive. That is
:more work for you, but it makes it easier on reviewers, and it is
:certainly consistent
Apparently, On Thu, Mar 07, 2002 at 07:04:49PM -0800,
Matthew Dillon said words to the effect of;
:Yes. What I would like and what I mentioned before is for this to be
:hidden behind cpu_critical_enter/exit. Specifically, cpu_critical_enter
:would be a null macro for i386, which
On 05-Mar-02 Matthew Dillon wrote:
: It makes no sense whatsoever to me to be told not to commit something
: due to stale code that may not be quite compatible sitting in P4 that
: you can't make work in any reasonable time frame. You should stop
: trying to screw over my work
:Have you read the paper I posted to arch? It quite clearly (I thought)
:explained the role of the critical_* and the cpu_critical_* in the preemption
:code. It should be rather obvious from that why I don't want the critical_*
I'm sorry John, I have no idea what you are refering to here.
On Wed, 6 Mar 2002, Jeroen C.van Gelderen wrote:
Search for paper John Baldwin and find link 6:
A good start though incomplete. Unfortunate that it took such a fight to
get it to be written. Hopefully it's existance can prevent soem further
bloodshed. Is it possible for other people to add
:Search for paper John Baldwin and find link 6:
:
:http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=199282+204026+/usr/local/www/db/
:text/2002/freebsd-arch/20020303.freebsd-arch
:
:The actual paper is at:
: http://www.FreeBSD.org/~jhb/smpng/design/article.{ps,pdf}
:
:-J
:--
:Jeroen C. van
:stuff to change from their current model. I also think that just as it
:is too early to optimize to light weight ithread switches (sparc64 is
:going to optimize all kthread switches, not just ithreads by using a more
:general
We have very different development models, and different
:This same issue came up at the BSDCon developers conference in
:regard to ithreads. Is it better to optimize some bit of code
:because it is the fun and interesting thing to do, or to build a simple,
:yet stable and easily verified foundation, that we can later optimize
:in a controlled
:My 2 cents? Work with John to get the APIs that affect this particular
:code stable. That means discussion and perhaps that discussion will
:take some time (if this blow-up hadn't occurred the discussion
:would already be over now ;-). Once the APIs are in place, commit your
:code in a format
On 01-Mar-02 Matthew Dillon wrote:
:
:
:On 28-Feb-02 Matthew Dillon wrote:
: Not to put too fine a point on it, but, I don't see how this can
: possibly justify preventing me from committing my critical_*() stuff.
: You've just stated publically that your preemption stuff is
: It makes no sense whatsoever to me to be told not to commit something
: due to stale code that may not be quite compatible sitting in P4 that
: you can't make work in any reasonable time frame. You should stop
: trying to screw over my work and instead look to your own. You
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
That's the crux of the situation, John. I do not believe you have
the right to hold this work off, at least not based on any of the
explanations you have given so far.
Why don't you for a change, just stop being so ego-centered
On Tue, Mar 05, 2002 at 06:30:08PM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
That's the crux of the situation, John. I do not believe you have
the right to hold this work off, at least not based on any of the
explanations you have
Matthew Dillon wrote:
My patches have been tested, they work, and they ARE going to
be committed as soon as I am able to do so.
Tut, tut, looks like rain!
-- Winnie the Pooh; A. A. Milne
If you guys spent as much energy documenting your designs as
you
On Fri, 1 Mar 2002, Terry Lambert wrote:
I think the right thing to do is to commit the cred changes,
and stabilize them, if there's even a problem, as you expect
from your comments about dangerous.
John already committed a majority of all the cred changes.
I never saw a commit message
On 26-Feb-02 Julian Elischer wrote:
On Tue, 26 Feb 2002, John Baldwin wrote:
My suggestion will be to back it out. I would rather not have to make said
suggestion. Can you please try to fit this into the existing framework
rather
than ripping it all up? We need to finalize and test
yes but thete are subcommits that you could go ahead with...
the td_ucred stuff could have been checked in directly into -current.
On Thu, 28 Feb 2002, John Baldwin wrote:
On 26-Feb-02 Julian Elischer wrote:
On Tue, 26 Feb 2002, John Baldwin wrote:
My suggestion will be to back
Not to put too fine a point on it, but, I don't see how this can
possibly justify preventing me from committing my critical_*() stuff.
You've just stated publically that your preemption stuff is unusable
as it currently stands. Why am I supposed to wait an arbitrary period
of
On 28-Feb-02 Matthew Dillon wrote:
Not to put too fine a point on it, but, I don't see how this can
possibly justify preventing me from committing my critical_*() stuff.
You've just stated publically that your preemption stuff is unusable
as it currently stands. Why am I
:
:
:On 28-Feb-02 Matthew Dillon wrote:
: Not to put too fine a point on it, but, I don't see how this can
: possibly justify preventing me from committing my critical_*() stuff.
: You've just stated publically that your preemption stuff is unusable
: as it currently stands. Why
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
:Because the critical_* changes you are doing don't match up to the overall
:design. See my mail to -arch for more on that though. At some point in the
:future I think that this work can fit in rather well to the cpu_critical_foo
:stuff
:
:I strongly disagree. I have yet to see any technical description of
:this so-called overall design that shows any incompatibility, and what
:I decide to do with my time is my business.
:
:Matt,
:
:That particular protest is rather hollow, considering that you were
:one of the
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
:
:I strongly disagree. I have yet to see any technical description of
:this so-called overall design that shows any incompatibility, and what
:I decide to do with my time is my business.
:
:Matt,
:
:That particular protest is
:John has been consistently chugging along on the job all the way.
:At this point in time, until he is officially unseated John is our
:designated SMPng architect and his word is pretty final.
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
Oooh... so you mean that since I was
On 26-Feb-02 Matthew Dillon wrote:
:1) I had an ugly panic testing it on the alpha. After a good deal of
:sleuthing,
: I've determined that we still have some preemption related bugs in
: possibly
: the alpha pmap, but that td_ucred isn't the problem.
:2) I've been thinking about the
On 26-Feb-02 Bruce Evans wrote:
On Tue, 26 Feb 2002, John Baldwin wrote:
The critical section stuff currently in current is part of the original
preemption patches I wrote at Usenix last year. They aren't in the tree
because they aren't stable yet. We still have problems on the alpha and
:..
: cpu_critical_enter() to a null version to prevent spinlocks masking
: interrupts doesn't work very well because it is used for other things
: that really do need to mask interrupts. Having 2 levels for
: cpu_critical_enter() (on that masks normal interrupts and one that
: masks fast
On Tue, 26 Feb 2002, John Baldwin wrote:
My suggestion will be to back it out. I would rather not have to make said
suggestion. Can you please try to fit this into the existing framework rather
than ripping it all up? We need to finalize and test the design before we
hardcode too many
On 26-Feb-02 Peter Wemm wrote:
Matthew Dillon wrote:
:
:On Mon, 25 Feb 2002, Matthew Dillon wrote:
:
: Unless an unforseen problem arises, I am going to commit this
: tomorrow
: and then start working on a cleanup patch. I have decided to
:
:Please wait for jhb's opinion
On 26-Feb-02 Matthew Dillon wrote:
:
:On Mon, 25 Feb 2002, Matthew Dillon wrote:
:
: Unless an unforseen problem arises, I am going to commit this tomorrow
: and then start working on a cleanup patch. I have decided to
:
:Please wait for jhb's opinion on it. He seems to be offline
:1) I had an ugly panic testing it on the alpha. After a good deal of sleuthing,
: I've determined that we still have some preemption related bugs in possibly
: the alpha pmap, but that td_ucred isn't the problem.
:2) I've been thinking about the Giant instrumentation a bit. I figured out
On Tue, 26 Feb 2002, John Baldwin wrote:
The critical section stuff currently in current is part of the original
preemption patches I wrote at Usenix last year. They aren't in the tree
because they aren't stable yet. We still have problems on the alpha and
problems with IPI deadlocks on
: The critical section stuff currently in current is part of the original
: preemption patches I wrote at Usenix last year. They aren't in the tree
: because they aren't stable yet. We still have problems on the alpha and
: problems with IPI deadlocks on SMP machines that need to be worked
73 matches
Mail list logo
