On Sat, 4 Nov 2000, Alan Cox wrote:
> > sysv semaphores have a very unfortunate negative feature -- if the admin
> > kill -9's the server (impatient admins do this all the time) then you end
> > up leaving a semaphore lying around. sysvsem don't have the usual unix
>
> Umm they have SEM_UNDO.
Linus Torvalds wrote:
>
> No.
>
> Please use unserialized accept() _always_, because we can fix that.
>
> Even 2.2.x can be fixed to do the wake-one for accept(), if required.
> It's not going to be any worse than the current apache config, and
> basically the less games apache plays, the better
> sysv semaphores have a very unfortunate negative feature -- if the admin
> kill -9's the server (impatient admins do this all the time) then you end
> up leaving a semaphore lying around. sysvsem don't have the usual unix
Umm they have SEM_UNDO. Its a case of deeper magic
-
To unsubscribe
> > Instead, if apache had just done the thing it wanted to do in the first
> > place, the wake-one accept() semantics would have happened a hell of a
> > lot earlier.
>
> counter-example: freebsd had wake-one semantics a few years before linux.
And Im sure apache authors can use the utsname()
On Sat, 4 Nov 2000, Andrew Morton wrote:
> Dean,
>
> neither flock() nor fcntl() serialisation are effective
> on linux 2.2 or linux 2.4.
i have to admit the last time i timed any of the methods on linux was in
2.0.x days. thanks for the updated data!
> For kernel 2.2 I recommend that Apache
On Fri, 3 Nov 2000, Linus Torvalds wrote:
> Please use unserialized accept() _always_, because we can fix that.
i can unserialise the single socket case, but the multiple socket case is
not so simple.
the executive summary is that when you've got multiple sockets you have to
use select().
On Sat, 4 Nov 2000, Andrew Morton wrote:
Dean,
neither flock() nor fcntl() serialisation are effective
on linux 2.2 or linux 2.4.
i have to admit the last time i timed any of the methods on linux was in
2.0.x days. thanks for the updated data!
For kernel 2.2 I recommend that Apache
sysv semaphores have a very unfortunate negative feature -- if the admin
kill -9's the server (impatient admins do this all the time) then you end
up leaving a semaphore lying around. sysvsem don't have the usual unix
Umm they have SEM_UNDO. Its a case of deeper magic
-
To unsubscribe from
On Sat, 4 Nov 2000, Alan Cox wrote:
sysv semaphores have a very unfortunate negative feature -- if the admin
kill -9's the server (impatient admins do this all the time) then you end
up leaving a semaphore lying around. sysvsem don't have the usual unix
Umm they have SEM_UNDO. Its a
On Fri, 3 Nov 2000, Linus Torvalds wrote:
Please use unserialized accept() _always_, because we can fix that.
i can unserialise the single socket case, but the multiple socket case is
not so simple.
the executive summary is that when you've got multiple sockets you have to
use select().
Instead, if apache had just done the thing it wanted to do in the first
place, the wake-one accept() semantics would have happened a hell of a
lot earlier.
counter-example: freebsd had wake-one semantics a few years before linux.
And Im sure apache authors can use the utsname() syscall
Linus Torvalds wrote:
No.
Please use unserialized accept() _always_, because we can fix that.
Even 2.2.x can be fixed to do the wake-one for accept(), if required.
It's not going to be any worse than the current apache config, and
basically the less games apache plays, the better the
In article <[EMAIL PROTECTED]>,
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>neither flock() nor fcntl() serialisation are effective
>on linux 2.2 or linux 2.4. This is because the file
>locking code still wakes up _all_ waiters. In my testing
>with fcntl serialisation I have seen a single
dean gaudet wrote:
>
> On Tue, 31 Oct 2000, Andrew Morton wrote:
>
> > Dean, it looks like the same problem will occur with flock()-based
> > serialisation. Does Apache/Linux ever use that option?
>
> from apache/src/include/ap_config.h in the linux section there's
> this:
>
> /* flock is
[EMAIL PROTECTED] wrote:
>
> Andrew Morton writes:
> > This patch is a moderate rewrite of __wake_up_common. I'd be
> > interested in seeing how much difference it makes to the
> > performance of Apache when the file-locking serialisation is
> > disabled.
> > - It implements
In article [EMAIL PROTECTED],
Andrew Morton [EMAIL PROTECTED] wrote:
neither flock() nor fcntl() serialisation are effective
on linux 2.2 or linux 2.4. This is because the file
locking code still wakes up _all_ waiters. In my testing
with fcntl serialisation I have seen a single Apache
[EMAIL PROTECTED] wrote:
Andrew Morton writes:
This patch is a moderate rewrite of __wake_up_common. I'd be
interested in seeing how much difference it makes to the
performance of Apache when the file-locking serialisation is
disabled.
- It implements last-in/first-out
dean gaudet wrote:
On Tue, 31 Oct 2000, Andrew Morton wrote:
Dean, it looks like the same problem will occur with flock()-based
serialisation. Does Apache/Linux ever use that option?
from apache/src/include/ap_config.h in the linux section there's
this:
/* flock is faster ...
On Mon, Oct 30, 2000 at 02:36:39PM -0200, Rik van Riel wrote:
> For stuff like ___wait_on_page(), OTOH, you really want FIFO
> wakeup to avoid starvation (yes, I know we're currently doing
Sure agreed. In my _whole_ previous email I was only talking about accept.
Semaphores file locking etc..
On Mon, Oct 30, 2000 at 02:36:39PM -0200, Rik van Riel wrote:
For stuff like ___wait_on_page(), OTOH, you really want FIFO
wakeup to avoid starvation (yes, I know we're currently doing
Sure agreed. In my _whole_ previous email I was only talking about accept.
Semaphores file locking etc.. all
On Sun, Oct 29, 2000 at 11:45:49AM -0800, dean gaudet wrote:
> On Sat, 28 Oct 2000, Alan Cox wrote:
>
> > > The big question is: why is Apache using file locking so
> > > much? Is this normal behaviour for Apache?
> >
> > Apache uses file locking to serialize accept on hosts where accept
On Sun, Oct 29, 2000 at 11:45:49AM -0800, dean gaudet wrote:
On Sat, 28 Oct 2000, Alan Cox wrote:
The big question is: why is Apache using file locking so
much? Is this normal behaviour for Apache?
Apache uses file locking to serialize accept on hosts where accept either has
bad
Andrew Morton wrote:
>
> I think it's more expedient at this time to convert
> acquire_fl_sem/release_fl_sem into lock_kernel/unlock_kernel
> (so we _can_ sleep) and to fix the above alleged deadlock
> via the creation of __posix_unblock_lock()
I agree with me. Could you please test the
Andrew Morton wrote:
> --- linux-2.4.0-test10-pre5/fs/locks.c Tue Oct 24 21:34:13 2000
> +++ linux-akpm/fs/locks.c Sun Oct 29 02:31:10 2000
> @@ -125,10 +125,9 @@
> #include
> #include
>
> -DECLARE_MUTEX(file_lock_sem);
> -
> -#define acquire_fl_sem() down(_lock_sem)
> -#define
On Sun, Oct 29, 2000 at 02:46:14AM +1100, Andrew Morton wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Change the following two macros:
> > acquire_fl_sem()->lock_kernel()
> > release_fl_sem()->unlock_kernel()
> > then
> > 5192 Req/s @8cpu is got. It is same as test8 within
[EMAIL PROTECTED] wrote:
>
> Change the following two macros:
> acquire_fl_sem()->lock_kernel()
> release_fl_sem()->unlock_kernel()
> then
> 5192 Req/s @8cpu is got. It is same as test8 within fluctuation.
hmm.. BKL increases scalability. News at 11.
The big question is: why
Andrew Morton wrote:
I think it's more expedient at this time to convert
acquire_fl_sem/release_fl_sem into lock_kernel/unlock_kernel
(so we _can_ sleep) and to fix the above alleged deadlock
via the creation of __posix_unblock_lock()
I agree with me. Could you please test the scalability
[EMAIL PROTECTED] wrote:
Change the following two macros:
acquire_fl_sem()-lock_kernel()
release_fl_sem()-unlock_kernel()
then
5192 Req/s @8cpu is got. It is same as test8 within fluctuation.
hmm.. BKL increases scalability. News at 11.
The big question is: why is
On Sun, Oct 29, 2000 at 02:46:14AM +1100, Andrew Morton wrote:
[EMAIL PROTECTED] wrote:
Change the following two macros:
acquire_fl_sem()-lock_kernel()
release_fl_sem()-unlock_kernel()
then
5192 Req/s @8cpu is got. It is same as test8 within fluctuation.
hmm..
Andrew Morton wrote:
--- linux-2.4.0-test10-pre5/fs/locks.c Tue Oct 24 21:34:13 2000
+++ linux-akpm/fs/locks.c Sun Oct 29 02:31:10 2000
@@ -125,10 +125,9 @@
#include asm/semaphore.h
#include asm/uaccess.h
-DECLARE_MUTEX(file_lock_sem);
-
-#define acquire_fl_sem()
30 matches
Mail list logo
