Messages in this thread | | | Subject | Re: Bloat? (khttpd) | From | James Antill <> | Date | 24 Dec 1999 14:38:22 -0500 |
| |
Lincoln Dale <ltd@interlink.com.au> writes:
> At 02:49 24/12/99 +0100, Martin Dalecki wrote: > >Lincoln Dale wrote: > > > > > > At 19:33 23/12/99 -0500, Mark Hahn wrote: > > > >so far, we have no reason to believe that khttpd performs better than, > > > >say, phhttbd, even on silly static-only benchmarks. and even if it did, > > > >the sensible conclusion would be that there's something wrong with Linux, > > > >not that webserving should be in the kernel! > > > > > > actually, khttpd does get around one limitation currently inherent inside > > > linux -- > > > and that is that there is no mechanism for zero-copy. > > > >Wrong. There is the sendfile syscall. > > ... which, in turn, has its own inherent scaling problems. > care to have 30,000 simultaneous streams open? > > last time i looked, context was held on a per-user-thread. there was some > relatively-recent discussion on changing its semantics to no longer be a > blocking syscall, but i don't think there much final consensus out of that.
If the fd you are sending from or to is O_NONBLOCK then it isn't a blocking syscall (AFAIK -- and looking at the source if file_send_actor() used in sys_sendfile() returns 0 then do_generic_file_read() finishes). Obviously assuming file->f_op->write doesn't always block, but I think that's a fair assumption.
Maybe you mean that _currently_ the kernel only allows you to call sendfile() with a from_fd of an on actual file and files don't honour O_NONBLOCK, but that isn't the same thing. IMO it's like saying write() is always blocking because it will always page in the buffer.
-- James Antill -- james@and.org I am always an optimist, but frankly there is no hope. -Hosni Mubarek
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |