Re: ARP out the wrong interface

oops typo. On Thu, 8 Feb 2001, dean gaudet wrote: > this appears to occur with both 2.2.16 and 2.4.1. > > server: > > eth0 is 192.168.250.11 netmask 255.255.255.0 > eth1 is 192.168.251.11 netmask 255.255.255.0 > > they're both connected to the same switch. > > clie

ARP out the wrong interface

this appears to occur with both 2.2.16 and 2.4.1. server: eth0 is 192.168.250.11 netmask 255.255.255.0 eth1 is 192.168.251.11 netmask 255.255.255.0 they're both connected to the same switch. client: eth0 is 192.168.251.11 netmask 255.255.255.0 connected to the same switch as both of

Re: dentry cache order 7 is broken

that appears to do it :) -dean On Thu, 8 Feb 2001, David S. Miller wrote: > > dean gaudet writes: > > also, for order > 7, was the real intention to use a shift of > > (order*2)&31? > > No, the whole thing is buggered. How stupid, my fault. > It was t

ARP out the wrong interface

this appears to occur with both 2.2.16 and 2.4.1. server: eth0 is 192.168.250.11 netmask 255.255.255.0 eth1 is 192.168.251.11 netmask 255.255.255.0 they're both connected to the same switch. client: eth0 is 192.168.251.11 netmask 255.255.255.0 connected to the same switch as both of

Re: ARP out the wrong interface

oops typo. On Thu, 8 Feb 2001, dean gaudet wrote: this appears to occur with both 2.2.16 and 2.4.1. server: eth0 is 192.168.250.11 netmask 255.255.255.0 eth1 is 192.168.251.11 netmask 255.255.255.0 they're both connected to the same switch. client: eth0 is 192.168.251.11 netmask

dentry cache order 7 is broken

this looks to be a problem going back all the way to at least 2.2. if you've got 512Mb of RAM you end up with a dentry cache of order 7 -- 65536 entries. this results in a D_HASHBITS of 16. if you look at d_hash it contains this code: hash = hash ^ (hash >> D_HASHBITS) ^ (hash >>

dentry cache order 7 is broken

this looks to be a problem going back all the way to at least 2.2. if you've got 512Mb of RAM you end up with a dentry cache of order 7 -- 65536 entries. this results in a D_HASHBITS of 16. if you look at d_hash it contains this code: hash = hash ^ (hash D_HASHBITS) ^ (hash

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On 20 Jan 2001, Kai Henningsen wrote: > [EMAIL PROTECTED] (dean gaudet) wrote on 18.01.01 in ><[EMAIL PROTECTED]>: > > > i'm pretty sure the actual use of pipelining is pretty disappointing. > > the work i did in apache preceded the widespread use of HTTP/1.1 and

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On 20 Jan 2001, Kai Henningsen wrote: [EMAIL PROTECTED] (dean gaudet) wrote on 18.01.01 in [EMAIL PROTECTED]: i'm pretty sure the actual use of pipelining is pretty disappointing. the work i did in apache preceded the widespread use of HTTP/1.1 and we What widespread use of HTTP/1.1

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

nly i had a portable version of this :) -dean On Thu, 18 Jan 2001, dean gaudet wrote: > huh -- i think with this apache could solve the problem documented in > heidemann's paper while also leaving nagle on... which would solve the CGI > dribbler vs. bulk problem i just posted about. >

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

huh -- i think with this apache could solve the problem documented in heidemann's paper while also leaving nagle on... which would solve the CGI dribbler vs. bulk problem i just posted about. at the end of a request apache would check first if it can get another request without blocking; if it

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Zach Brown wrote: > We set TCP_CORK on the socket we handed to external programs that were > being run via 'site exec' in an ftp server. It resulted in much nicer > packets being spit out, especially in the 'ls' case where it likes to > write() on really goofy boundaries. >

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

alised (because they're being pretty ambitious); and nobody has decided to just forge forward and layer HTTP/1.1 on top of WebMUX yet. (the subversive in me wants to see WebMUX patches for apache, squid, and mozilla ;) -dean On Thu, 18 Jan 2001, dean gaudet wrote: > On Wed, 17 Jan 2

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Wed, 17 Jan 2001, Rick Jones wrote: > > actually the problem isn't nagle... nagle needs to be turned off for > > efficient servers anyhow. > > i'm not sure I follow that. could you expand on that a bit? the problem which caused us to disable nagle in apache is documented in this paper

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Wed, 17 Jan 2001, Rick Jones wrote: actually the problem isn't nagle... nagle needs to be turned off for efficient servers anyhow. i'm not sure I follow that. could you expand on that a bit? the problem which caused us to disable nagle in apache is documented in this paper

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

(because they're being pretty ambitious); and nobody has decided to just forge forward and layer HTTP/1.1 on top of WebMUX yet. (the subversive in me wants to see WebMUX patches for apache, squid, and mozilla ;) -dean On Thu, 18 Jan 2001, dean gaudet wrote: On Wed, 17 Jan 2001, Rick Jones w

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, 18 Jan 2001, Zach Brown wrote: We set TCP_CORK on the socket we handed to external programs that were being run via 'site exec' in an ftp server. It resulted in much nicer packets being spit out, especially in the 'ls' case where it likes to write() on really goofy boundaries.

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

huh -- i think with this apache could solve the problem documented in heidemann's paper while also leaving nagle on... which would solve the CGI dribbler vs. bulk problem i just posted about. at the end of a request apache would check first if it can get another request without blocking; if it

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

nly i had a portable version of this :) -dean On Thu, 18 Jan 2001, dean gaudet wrote: huh -- i think with this apache could solve the problem documented in heidemann's paper while also leaving nagle on... which would solve the CGI dribbler vs. bulk problem i just posted about. at the end of a

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Wed, 17 Jan 2001, Rick Jones wrote: > > The fact that I understand _why_ it is done that way doesn't mean that I > > don't think it's a hack. It doesn't allow you to sendfile multiple files > > etc without having nagle boundaries, and the header/trailer stuff really > > isn't a generic

Re: Is sendfile all that sexy?

On Tue, 16 Jan 2001, David L. Parsley wrote: > Felix von Leitner wrote: > > > close (0); > > > close (1); > > > close (2); > > > open ("/dev/console", O_RDWR); > > > dup (); > > > dup (); > > > > So it's not actually part of POSIX, it's just to get around fixing > > legacy code? ;-)

Re: Is sendfile all that sexy?

On Tue, 16 Jan 2001, David L. Parsley wrote: Felix von Leitner wrote: close (0); close (1); close (2); open ("/dev/console", O_RDWR); dup (); dup (); So it's not actually part of POSIX, it's just to get around fixing legacy code? ;-) it's part of POSIX.

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Wed, 17 Jan 2001, Rick Jones wrote: The fact that I understand _why_ it is done that way doesn't mean that I don't think it's a hack. It doesn't allow you to sendfile multiple files etc without having nagle boundaries, and the header/trailer stuff really isn't a generic solution.

Re: 'native files', 'object fingerprints' [was: sendpath()]

On Tue, 16 Jan 2001, Ingo Molnar wrote: > But even user-space code could use 'native files', via the following, safe > mechanizm: so here's an alternative to ingo's proposal which i think solves some of the other objections raised. it's something i've proposed in the past under the name

Re: [patch] sendpath() support, 2.4.0-test3/-ac9

On Tue, 16 Jan 2001, Ingo Molnar wrote: > > On Mon, 15 Jan 2001, dean gaudet wrote: > > > > just for kicks i've implemented sendpath() support. > > > > > > _syscall4 (int, sendpath, int, out_fd, char *, path, off_t *, off, size_t, size) > > > &g

Re: [patch] sendpath() support, 2.4.0-test3/-ac9

On Tue, 16 Jan 2001, Ingo Molnar wrote: On Mon, 15 Jan 2001, dean gaudet wrote: just for kicks i've implemented sendpath() support. _syscall4 (int, sendpath, int, out_fd, char *, path, off_t *, off, size_t, size) hey so how do you implement transmit timeouts with sendpath

Re: 'native files', 'object fingerprints' [was: sendpath()]

On Tue, 16 Jan 2001, Ingo Molnar wrote: But even user-space code could use 'native files', via the following, safe mechanizm: so here's an alternative to ingo's proposal which i think solves some of the other objections raised. it's something i've proposed in the past under the name

Re: [patch] sendpath() support, 2.4.0-test3/-ac9

On Mon, 15 Jan 2001, Ingo Molnar wrote: > just for kicks i've implemented sendpath() support. > > _syscall4 (int, sendpath, int, out_fd, char *, path, off_t *, off, size_t, size) hey so how do you implement transmit timeouts with sendpath() ? (i.e. drop the client after 30 seconds of no

Re: Is sendfile all that sexy?

On Mon, 15 Jan 2001, Jonathan Thackray wrote: > > TCP_CORK is useful for FAR more than just sendfile() headers and > > footers. it's arguably the most correct way to write server code. > > Agreed -- the hard-coded Nagle algorithm makes no sense these days. hey, actually a little more

Re: Is sendfile all that sexy?

On Mon, 15 Jan 2001, Jonathan Thackray wrote: > (Linux, FreeBSD, HP-UX, AIX, Tru64). The next cool feature to add to > Linux is sendpath(), which does the open() before the sendfile() > all combined into one system call. how would sendpath() construct the Content-Length in the HTTP header?

Re: Is sendfile all that sexy?

On Mon, 15 Jan 2001, Jonathan Thackray wrote: (Linux, FreeBSD, HP-UX, AIX, Tru64). The next cool feature to add to Linux is sendpath(), which does the open() before the sendfile() all combined into one system call. how would sendpath() construct the Content-Length in the HTTP header? it's

Re: Is sendfile all that sexy?

On Mon, 15 Jan 2001, Jonathan Thackray wrote: TCP_CORK is useful for FAR more than just sendfile() headers and footers. it's arguably the most correct way to write server code. Agreed -- the hard-coded Nagle algorithm makes no sense these days. hey, actually a little more thinking this

Re: Keeping track of socket settings...

On Sun, 7 Jan 2001, David Reid wrote: Greg, Nicely put and that's exactly what I had in mind but after spending 10 hours flogging to St Pete back my mind isn't working as well as normal! (Mind due, does it ever??) Of course I was going to use the TCP_ flags but the APR should do the

Re: khttpd beats boa with persistent patch

a few comments... - localhost is a meaningless benchmark. it's useful to catch some low hanging fruit, but it really doesn't help in the long run. - contrast the max connection times between kHTTPd and Boa. if that 9 second maximum for kHTTPd is any indication of its latency performance on a

Re: khttpd beats boa with persistent patch

a few comments... - localhost is a meaningless benchmark. it's useful to catch some low hanging fruit, but it really doesn't help in the long run. - contrast the max connection times between kHTTPd and Boa. if that 9 second maximum for kHTTPd is any indication of its latency performance on a

Re: Poll and Select not scaling

On Wed, 10 Jan 2001, Dan Kegel wrote: > select() is usually limited to 1024 file descriptors oh hey, this limit is only a libc limit these days. you can do this: #define MY_FD_SETSIZE (16384) typedef struct { __fd_mask __fds_bits[MY_FD_SETSIZE / __NFDBITS]; } my_fd_set; #define

Re: Poll and Select not scaling

On Wed, 10 Jan 2001, Dan Kegel wrote: select() is usually limited to 1024 file descriptors oh hey, this limit is only a libc limit these days. you can do this: #define MY_FD_SETSIZE (16384) typedef struct { __fd_mask __fds_bits[MY_FD_SETSIZE / __NFDBITS]; } my_fd_set; #define

Re: storage over IP (was Re: [PLEASE-TESTME] Zerocopy networkingpatch, 2.4.0-1)

On Tue, 9 Jan 2001, David S. Miller wrote: >Date: Tue, 9 Jan 2001 18:56:33 -0800 (PST) >From: dean gaudet <[EMAIL PROTECTED]> > >is NFS receive single copy today? > > With the zerocopy patches, NFS client receive is "single cpu copy" if > that'

storage over IP (was Re: [PLEASE-TESTME] Zerocopy networking patch,2.4.0-1)

On Tue, 9 Jan 2001, Ingo Molnar wrote: > On Mon, 8 Jan 2001, Rik van Riel wrote: > > > Having proper kiobuf support would make it possible to, for example, > > do zerocopy network->disk data transfers and lots of other things. > > i used to think that this is useful, but these days it isnt.

storage over IP (was Re: [PLEASE-TESTME] Zerocopy networking patch,2.4.0-1)

On Tue, 9 Jan 2001, Ingo Molnar wrote: On Mon, 8 Jan 2001, Rik van Riel wrote: Having proper kiobuf support would make it possible to, for example, do zerocopy network-disk data transfers and lots of other things. i used to think that this is useful, but these days it isnt. this seems

Re: storage over IP (was Re: [PLEASE-TESTME] Zerocopy networkingpatch, 2.4.0-1)

On Tue, 9 Jan 2001, David S. Miller wrote: Date: Tue, 9 Jan 2001 18:56:33 -0800 (PST) From: dean gaudet [EMAIL PROTECTED] is NFS receive single copy today? With the zerocopy patches, NFS client receive is "single cpu copy" if that's what you mean. yeah sorry, i mea

buckets and rputs/rprintf

-- Reply-To: new-httpd@apache.org Date: Sun, 7 Jan 2001 11:51:47 -0800 (PST) From: dean gaudet [EMAIL PROTECTED] To: new-httpd@apache.org Subject: woah, GET / with autoindex X-comment: visit http://arctic.org/~dean/legal for information regarding copyright and disclaimer. woah. ok

Re: linux 2.2.19pre and thttpd (VM-global problem?)

On Fri, 29 Dec 2000, Andrea Arcangeli wrote: > On Fri, Dec 29, 2000 at 06:50:18PM +, Alan Cox wrote: > > Your cgi will keep the other CPU occupied, or run two of them. thttpd has > > superb scaling properties compared to say apache. > > I think with 8 CPUs and 8 NICs (usual benchmark setup)

Re: linux 2.2.19pre and thttpd (VM-global problem?)

On Fri, 29 Dec 2000, Andrea Arcangeli wrote: On Fri, Dec 29, 2000 at 06:50:18PM +, Alan Cox wrote: Your cgi will keep the other CPU occupied, or run two of them. thttpd has superb scaling properties compared to say apache. I think with 8 CPUs and 8 NICs (usual benchmark setup) you

Re: how to capture long oops w/o having second machine

i've always been curious why none of the crash dump patches are default. an oops dumper alone would seem to be most useful. (i know anything more would be unacceptable 'cause linus isn't into debuggers ;) -dean On Tue, 12 Dec 2000, Miles Lane wrote: > > Try reading: > >

Re: how to capture long oops w/o having second machine

i've always been curious why none of the crash dump patches are default. an oops dumper alone would seem to be most useful. (i know anything more would be unacceptable 'cause linus isn't into debuggers ;) -dean On Tue, 12 Dec 2000, Miles Lane wrote: Try reading:

Re: [PATCH] Re: Negative scalability by removal of

ate: Mon, 6 Nov 2000 21:23:57 -0800 (PST) >From: dean gaudet <[EMAIL PROTECTED]> > > apache is about correctness first, and performance second. > > Which is why we say it is "incorrect" for apache to try > and work around kernel performance problems

Re: [PATCH] Re: Negative scalability by removal of

: Mon, 6 Nov 2000 21:23:57 -0800 (PST) From: dean gaudet [EMAIL PROTECTED] apache is about correctness first, and performance second. Which is why we say it is "incorrect" for apache to try and work around kernel performance problems. :-))) Later, David S. Mill

Re: [PATCH] Re: Negative scalability by removal of

On Mon, 6 Nov 2000, Linus Torvalds wrote: > This is why I'd love to _not_ see silly work-arounds in apache hey, maybe it's time for me to repeat something that i'm often quoted as saying: apache is about correctness first, and performance second. i don't think that's silly personally.

Re: Can EINTR be handled the way BSD handles it? -- a plea from auser-land programmer...

On Mon, 6 Nov 2000, George Talbot wrote: > I respectfully disagree that programs which don't surround some of the > most common system calls with > > do > { > rv = __some_system_call__(...); > } while (rv == -1 && errno == EINTR); welcome to Unix. this is how

Re: Can EINTR be handled the way BSD handles it? -- a plea from auser-land programmer...

On Mon, 6 Nov 2000, George Talbot wrote: I respectfully disagree that programs which don't surround some of the most common system calls with do { rv = __some_system_call__(...); } while (rv == -1 errno == EINTR); welcome to Unix. this is how it is, and

Re: [PATCH] Re: Negative scalability by removal of

the numbers didn't look that bad for the small numbers of concurrent clients on 2.2... a few % slower without the serialisation. compared to orders of magnitude slower with large numbers of concurrent client. oh, someone reminded me of the other reason sysvsems suck: a cgi can grab the

Re: [PATCH] Re: Negative scalability by removal of

the numbers didn't look that bad for the small numbers of concurrent clients on 2.2... a few % slower without the serialisation. compared to orders of magnitude slower with large numbers of concurrent client. oh, someone reminded me of the other reason sysvsems suck: a cgi can grab the

Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strange

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.

Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strangeperformance behavior of 2.4.0-test9)

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

Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strangeperformance behavior of 2.4.0-test9)

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().

Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strangeperformance behavior of 2.4.0-test9)

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

Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strange

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

Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strangeperformance behavior of 2.4.0-test9)

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().

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land programmer...

On Fri, 3 Nov 2000 [EMAIL PROTECTED] wrote: > I don't mean this to sound like a rant. It's just that I can't possibly > ascertain why someone in their right mind would want any behaviour > different than SA_RESTART. study apache 1.3's child_main code, you'll see an example of EINTR in use.

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land programmer...

On Fri, 3 Nov 2000 [EMAIL PROTECTED] wrote: I don't mean this to sound like a rant. It's just that I can't possibly ascertain why someone in their right mind would want any behaviour different than SA_RESTART. study apache 1.3's child_main code, you'll see an example of EINTR in use. it's

Re: select() bug

> > Semantic issues aside, since Apache does the test I mentionned earlier > > to determine child status and since it could be misled, should this > > feature be turned off? > > Or made smarter yes i'm scratching my head wondering what i was thinking when i wrote that code. the specific thing

Re: select() bug

Semantic issues aside, since Apache does the test I mentionned earlier to determine child status and since it could be misled, should this feature be turned off? Or made smarter yes i'm scratching my head wondering what i was thinking when i wrote that code. the specific thing the

Re: 2.2 generating odd TCP resets?

On Wed, 18 Oct 2000, Brian Craft wrote: > In the code below, I removed the shutdown() and added the block > after do_scan() to eliminate the RST. The read() never finds any data. > If there's no data pending, why does read() have any affect? EOF is considered pending data... and has to be read.

Re: 2.2 generating odd TCP resets?

On Wed, 18 Oct 2000, Brian Craft wrote: In the code below, I removed the shutdown() and added the block after do_scan() to eliminate the RST. The read() never finds any data. If there's no data pending, why does read() have any affect? EOF is considered pending data... and has to be read.

Re: Linux-2.4.0-test8-pre6

On Thu, 7 Sep 2000, Bill Wendling wrote: > Also sprach dean gaudet: > } On Wed, 6 Sep 2000, Linus Torvalds wrote: > } > } > Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that we > } > fixed it now several times, and I was always wrong. > } > } o

Re: Linux-2.4.0-test8-pre6

On Wed, 6 Sep 2000, Linus Torvalds wrote: > Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that we > fixed it now several times, and I was always wrong. obpainintheass: haven't you anti-debugger-religion folks been claiming that if you don't have a debugger you're forced to

Re: Linux-2.4.0-test8-pre6

On Wed, 6 Sep 2000, Linus Torvalds wrote: Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that we fixed it now several times, and I was always wrong. obpainintheass: haven't you anti-debugger-religion folks been claiming that if you don't have a debugger you're forced to

Re: Linux-2.4.0-test8-pre6

On Thu, 7 Sep 2000, Bill Wendling wrote: Also sprach dean gaudet: } On Wed, 6 Sep 2000, Linus Torvalds wrote: } } Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that we } fixed it now several times, and I was always wrong. } } obpainintheass: haven't you anti

Re: Availability of kdb

On Wed, 6 Sep 2000, Alan Cox wrote: > In many ways good crash dump tools and tracebacks (oopses do not count) are > the valuable bit - remote gdb happens to be a passable crash dump tool if you're lucky and can analyse the crash online, maybe. but offline crash dump analysis is the only option

Re: GPL violations: make it harder

sorry i should have pointed to this in my previous response -- read if you haven't already. (really wish i knew more about these topics outside the US... i'm even naive regarding these laws in my own home country Canada.) -dean - To unsubscribe from this

Re: GPL violations: make it harder

On Tue, 5 Sep 2000, Jeff Epler wrote: > strings plus code that I wrote. (My actual desire was to figure out a way > that I could release QuakeC modifications under the GPL, when the base > QuakeC source was not GPL. I hope there's no ethical brown stuff involved > in that desire!) assuming

Re: GPL violations: make it harder

On Tue, 5 Sep 2000, Mike A. Harris wrote: > If even one file in the kernel source gets modified, then the entire > patch is GPL via the GPL assimilation rules in COPYING - regardless of > what the author of the patch says. IANAL. i know this is what the GPL wants, but AFAIK it's never been

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

On Sun, 3 Sep 2000, Andre Hedrick wrote: > But there is no Copyright license in patch code. On Mon, 4 Sep 2000, Mike A. Harris wrote: > I was under the understanding a "patch" to something GPL, means > the "patch" is also GPL. when IBM started working with the apache group their lawyers did a

Re: zero-copy TCP

On Mon, 4 Sep 2000, Jamie Lokier wrote: > Alan Cox wrote: > > > It's not faster than card->card DMA, which falls out naturally from my > > > zero-copy proposal :-) > > > > We already support card->card DMA for routing with fastrouting > > ..but not for user space proxies which was the above's

O_CLOEXEC (was Re: thread rant)

On Sat, 2 Sep 2000, Alexander Viro wrote: > On Sat, 2 Sep 2000, Jamie Lokier wrote: > > > dean gaudet wrote: > > > an example of brokenness in the traditional fd API is close-on-exec -- > > > there's a race between open()/socket()/pipe() and fcntl(FD_CLOEXEC)

Re: zero-copy TCP

On Mon, 4 Sep 2000, Jamie Lokier wrote: Alan Cox wrote: It's not faster than card-card DMA, which falls out naturally from my zero-copy proposal :-) We already support card-card DMA for routing with fastrouting ..but not for user space proxies which was the above's context.

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

On Sun, 3 Sep 2000, Andre Hedrick wrote: But there is no Copyright license in patch code. On Mon, 4 Sep 2000, Mike A. Harris wrote: I was under the understanding a "patch" to something GPL, means the "patch" is also GPL. when IBM started working with the apache group their lawyers did a

Re: GPL violations: make it harder

On Tue, 5 Sep 2000, Mike A. Harris wrote: If even one file in the kernel source gets modified, then the entire patch is GPL via the GPL assimilation rules in COPYING - regardless of what the author of the patch says. IANAL. i know this is what the GPL wants, but AFAIK it's never been tested

Re: thread rant

On Sat, 2 Sep 2000, Ingo Molnar wrote: > i dont understand why this is such an important category. If the sharing > is very high between the threads then it makes sense to use 'shared-all > threads'. But frequently the example given are webservers, which often do > not have alot of cross-request

Re: thread rant

On Sat, 2 Sep 2000, Alexander Viro wrote: > *threads* *are* *hard* *to* *write* *correctly* in C, yes that can be essentially true. although you can do a webserver with no mutexes pretty easily... the first threaded apache had exactly one mutex -- inside the memory allocator when it had

Re: thread rant

On Sat, 2 Sep 2000, Ingo Molnar wrote: > > On Fri, 1 Sep 2000, dean gaudet wrote: > > > yup you can do this without threads. apache-1.3+mod_ssl for example. > > > > but it's not fun, and it's a lot more work on the portability side. > > inter-proces

Re: thread rant

On Fri, 1 Sep 2000, Mike A. Harris wrote: > I've heard comments from Alan, and others in the past bashing > threads, and I can understand the "threads are for people who > can't write state machines" comments I've heard, but what other > ways are there of accomplishing the goals that threads

Re: thread rant

On Fri, 1 Sep 2000, Michael Bacarella wrote: > Q: Why do we need threads? > A: Because on some operating systems, task switches are expensive. maybe this problem will help you understand threads better: design a webserver which supports SSL session keys. consider the performance of

Re: [PATCH] Fix disk statistic reporting to include all disks

On Tue, 29 Aug 2000, Linus Torvalds wrote: > On Wed, 30 Aug 2000, Jens Axboe wrote: > > > On Wed, Aug 30 2000, Jens Axboe wrote: > > > Sounds sane, but what about drivers that don't really use the request > > > queue structure? Stuff like lvm, md, rd (with Neil's patch to fix the > > > lru_list

Re: [PATCH] partial fix for Thinkpads and suspend

either /proc/sys or boot time options would work i'd think. and would be most most excellent :) then a wonderful project for someone to start would be userland tools that consult a database of laptop information and emit kernel tunings. -dean On Wed, 9 Aug 2000, Alan Cox wrote: #ifndef

Re: protocol/4716: Server send invalid response if chunked transfer has chunk larger than 4095 bytes. (fwd)

The following reply was made to PR protocol/4716; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: protocol/4716: Server send invalid response if chunked transfer has chunk larger than 4095 bytes. (fwd) Date: Thu, 12 Aug 1999 19:01:16 -0700

Re: cvs commit: apache-2.0/mpm/src/modules/mpm/mpmt_pthread mpmt_pthread.h Makefile.tmpl acceptlock.c acceptlock.h http_accept.c mpmt_pthread.c scoreboard.c

On 27 Jun 1999 [EMAIL PROTECTED] wrote: Index: ap_listen.h === RCS file: /home/cvs/apache-2.0/mpm/src/include/ap_listen.h,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -u -r1.1 -r1.2 ---

RE: protocol/3993: Incomplete Pages Loading Randomly (fwd)

The following reply was made to PR protocol/3993; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: RE: protocol/3993: Incomplete Pages Loading Randomly (fwd) Date: Sat, 1 May 1999 10:15:52 -0700 (PDT) -- Forwarded message

Re: os-linux/4268: Performance drops off after high specweb loads on highperformance-conf-dist

The following reply was made to PR os-linux/4268; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Karthik Prabhakar [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: os-linux/4268: Performance drops off after high specweb loads on highperformance-conf

Re: general/4160: Reading large amounts of data

The following reply was made to PR general/4160; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Peter Gordon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/4160: Reading large amounts of data Date: Sat, 1 May 1999 10:27:23 -0700 (PDT) On Thu, 22 Apr 1999

Re: general/4224: I get an inconsistend error, incomplete header sent error, but it works fine with ALL other browsers

The following reply was made to PR general/4224; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: John Saario [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/4224: I get an inconsistend error, incomplete header sent error, but it works fine with ALL other browsers

Re: os-linux/3343: Server dies after 1-20 hours of usage. (fwd)

The following reply was made to PR os-linux/3343; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: os-linux/3343: Server dies after 1-20 hours of usage. (fwd) Date: Sat, 1 May 1999 10:41:56 -0700 (PDT) -- Forwarded message

Re: os-linux/4268: Performance drops off after high specweb loads on highperformance-conf-dist (fwd)

The following reply was made to PR os-linux/4268; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: os-linux/4268: Performance drops off after high specweb loads on highperformance-conf-dist (fwd) Date: Wed, 21 Apr 1999 19:31:51 -0700 (PDT

Re: mod_cgi/3751: CGI scripts arent killed when they are in deadlock (fwd)

The following reply was made to PR mod_cgi/3751; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: mod_cgi/3751: CGI scripts arent killed when they are in deadlock (fwd) Date: Thu, 22 Apr 1999 02:41:41 -0700 (PDT) -- Forwarded

Re: general/3869: Server doesn't close connections after timeout period

Oh btw, here's a patch you might want to try. It's just a wild guess though. Dean Index: main/http_main.c === RCS file: /home/cvs/apache-1.3/src/main/http_main.c,v retrieving revision 1.430 diff -u -r1.430 http_main.c ---

Re: config/3906: Servers hang on either Keepalive or on Read (if keepalive is turned off)

BTW, here's a patch you may want to try. It's just a wild guess though... Dean Index: main/http_main.c === RCS file: /home/cvs/apache-1.3/src/main/http_main.c,v retrieving revision 1.430 diff -u -r1.430 http_main.c --- http_main.c

Re: mod_dir/3596: mod_dir doesn't handle requests which must be processed internally by mod_proxy

The following reply was made to PR mod_dir/3596; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Radu Greab [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_dir/3596: mod_dir doesn't handle requests which must be processed internally by mod_proxy Date: Wed, 21 Apr

Re: mod_log-any/3713: Piped Error Logs spawn extra process(es) (fwd)

The following reply was made to PR other/3713; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: mod_log-any/3713: Piped Error Logs spawn extra process(es) (fwd) Date: Wed, 21 Apr 1999 10:32:46 -0700 (PDT) -- Forwarded message

Re: mod_log-any/3802: would like to add an option,%R, to expand directory requests to include the filename within CLF (fwd)

The following reply was made to PR mod_log-any/3802; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: mod_log-any/3802: would like to add an option,%R, to expand directory requests to include the filename within CLF (fwd) Date: Wed, 21 Apr

<    4   5   6   7   8   9   10   11   12   13   >