Re: Ugly, slow shutdown

2000-08-15 Thread Peter Jeremy
On 2000-Aug-07 14:49:34 -0700, David Greenman [EMAIL PROTECTED] wrote: No, that's not true, and there are many examples in the kernel where a bogus wakeup would lead to bad things happening. I recall some code in the advisory locking code, and VM system, that assume that there is only one

Re: Ugly, slow shutdown

2000-08-11 Thread Stephen McKay
Well, I've failed in my main objective (to deuglify the shutdown messages), but an interesting debate has resulted instead, so I can't feel too bad. I did a little research to support my position on sleep/wakeup, and here's the best I have. This is pretty long, and unlikely to shake your world

Re: Ugly, slow shutdown

2000-08-11 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Stephen McKay writes: Regardless of the history of it all, FreeBSD is full of places where unexpected wakeups can stuff you right up. Should we regard tsleep() like the older sleep() call, as suspect, and program defensively? Should we be pragmatic, admit "We've

Re: Ugly, slow shutdown

2000-08-08 Thread David Greenman
In article [EMAIL PROTECTED], David Greenman [EMAIL PROTECTED] wrote: I will add that this is the pattern that Kirk teaches in his kernel internals class. If that's true, Do you want me to fax you a copy of page 15 of his class notes from the course he gave at last year's FreeBSDCon, or

Re: Ugly, slow shutdown

2000-08-08 Thread Alfred Perlstein
* David Greenman [EMAIL PROTECTED] [000807 23:15] wrote: In article [EMAIL PROTECTED], David Greenman [EMAIL PROTECTED] wrote: Obviously the waker-upper knows that the condition is true. Otherwise the existing code which doesn't check wouldn't work. In the expensive cases the waker-upper

Re: Ugly, slow shutdown

2000-08-08 Thread Nate Williams
It's not just that, if you always have to cover your behind when doing tsleep you may wind up masking wakeup bugs. Places like "vfs_bio.c" line 586 of 3182: bp-b_xflags |= BX_BKGRDWAIT; tsleep(bp-b_xflags, PRIBIO, "biord", 0); if (bp-b_xflags

Re: Ugly, slow shutdown

2000-08-07 Thread Sheldon Hearn
On Sun, 06 Aug 2000 01:49:49 +1000, Stephen McKay wrote: I think shutdown time has gotten uglier and slower than it needs to be. Probably because you already understand what's going on. The existing text for the "stopping process" messages is designed to help folks stay calm while their

Re: Ugly, slow shutdown

2000-08-07 Thread Alfred Perlstein
* Stephen McKay [EMAIL PROTECTED] [000805 08:49] wrote: Patch 2 is smaller and possibly controversial. Normally bufdaemon and syncer are sleeping when they are told to suspend. This delays shutdown by a few boring seconds. With this patch, it is zippier. I expect people to complain

Re: Ugly, slow shutdown

2000-08-07 Thread Mike Smith
* Stephen McKay [EMAIL PROTECTED] [000805 08:49] wrote: Patch 2 is smaller and possibly controversial. Normally bufdaemon and syncer are sleeping when they are told to suspend. This delays shutdown by a few boring seconds. With this patch, it is zippier. I expect people to

Re: Ugly, slow shutdown

2000-08-07 Thread Alfred Perlstein
* Mike Smith [EMAIL PROTECTED] [000807 01:25] wrote: * Stephen McKay [EMAIL PROTECTED] [000805 08:49] wrote: Patch 2 is smaller and possibly controversial. Normally bufdaemon and syncer are sleeping when they are told to suspend. This delays shutdown by a few boring seconds.

Re: Ugly, slow shutdown

2000-08-07 Thread Stephen McKay
* Mike Smith [EMAIL PROTECTED] [000807 01:25] wrote: * Stephen McKay [EMAIL PROTECTED] [000805 08:49] wrote: ... every sleeping process should expect to be woken for no reason at all. Basic kernel premise. You better bet it's controversial, this isn't "Basic kernel

Re: Ugly, slow shutdown

2000-08-07 Thread Warner Losh
In message [EMAIL PROTECTED] Stephen McKay writes: : And back to the simpler bit (the bike shed bit). Does everyone else actually : *like* the verbose messages currently used? And the gratuitous extra newline : in the "syncing..." message? I like the newer messages in your patch, but I don't

Re: Ugly, slow shutdown

2000-08-07 Thread Matt Dillon
: * Stephen McKay [EMAIL PROTECTED] [000805 08:49] wrote: : : Patch 2 is smaller and possibly controversial. Normally bufdaemon and : syncer are sleeping when they are told to suspend. This delays shutdown : by a few boring seconds. With this patch, it is zippier. I expect people : to

Re: Ugly, slow shutdown

2000-08-07 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Matt Dillon writes: : * Stephen McKay [EMAIL PROTECTED] [000805 08:49] wrote: : : Patch 2 is smaller and possibly controversial. Normally bufdaemon and : syncer are sleeping when they are told to suspend. This delays shutdown : by a few boring seconds. With

Re: Ugly, slow shutdown

2000-08-07 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Alfred Perlstein writes: Then this code should be changed to do the right thing, which is to *always* check the condition being slept on before proceeding. Can you give a reason why we'll have to now start coding defensively because our arguments to tsleep() are

Re: Ugly, slow shutdown

2000-08-07 Thread David Greenman
Can you give a reason why we'll have to now start coding defensively because our arguments to tsleep() are just "advisory" now? It is not something we "suddenly have to do" it's been The Right Way even since I first sharpened my teeth on unix kernels many years ago. Uh, Poul, I think you're

Re: Ugly, slow shutdown

2000-08-07 Thread Matt Dillon
Just a quick perusal of the kernel code shows a number of possible unexpected side effects from unexpected wakeups. I see several places where a 'WANTED' flag is set in a loop waiting for something and assumed to be cleared after the tsleep() returns. Some of these side effects

Re: Ugly, slow shutdown

2000-08-07 Thread Paul Richards
David Greenman wrote: Can you give a reason why we'll have to now start coding defensively because our arguments to tsleep() are just "advisory" now? It is not something we "suddenly have to do" it's been The Right Way even since I first sharpened my teeth on unix kernels many years ago.

Re: Ugly, slow shutdown

2000-08-07 Thread David Greenman
In the particular case of sleeping though, a woken process does need to check the condition that it slept on because one of the other processes sleeping on that resource may have had a chance to run first and changed some state. So as a general rule, you shouldn't assume that everything is fine

Re: Ugly, slow shutdown

2000-08-07 Thread Paul Richards
David Greenman wrote: In the particular case of sleeping though, a woken process does need to check the condition that it slept on because one of the other processes sleeping on that resource may have had a chance to run first and changed some state. So as a general rule, you shouldn't

Re: Ugly, slow shutdown

2000-08-07 Thread David Greenman
I did say "as a general rule". If you know that "by design" nothing else is going to mess with what you're sleeping on before you wake up then you can make tighter optimisations but that's not the general case. There is such a thing as over optimisation though and for the sake of a simple if

Re: Ugly, slow shutdown

2000-08-07 Thread John Polstra
In article [EMAIL PROTECTED], Alfred Perlstein [EMAIL PROTECTED] wrote: * Poul-Henning Kamp [EMAIL PROTECTED] [000807 10:03] wrote: Then this code should be changed to do the right thing, which is to *always* check the condition being slept on before proceeding. Can you give a reason

Re: Ugly, slow shutdown

2000-08-07 Thread David Greenman
I will add that this is the pattern that Kirk teaches in his kernel internals class. If that's true, then he should practice what he preaches. Some of the code that I'm refering to (e.g. lockf) was apparantly written by him. I'll say again, however, that some of the cases that rely on the

Re: Ugly, slow shutdown

2000-08-07 Thread John Polstra
In article [EMAIL PROTECTED], David Greenman [EMAIL PROTECTED] wrote: I will add that this is the pattern that Kirk teaches in his kernel internals class. If that's true, Do you want me to fax you a copy of page 15 of his class notes from the course he gave at last year's FreeBSDCon, or