sendfile() documentation
Johnny Teveßen
I'd like to have a look at sendfile(). Where can I lookup
the matching documentation/manpage on the API? mm/filemap.c is not
very verbose at all. Do I need to use glibc to use sendfile()?
ciao,
johnny
--
Trust no-one.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Pawel Krawczyk
> I'd like to have a look at sendfile(). Where can I lookup
> the matching documentation/manpage on the API? mm/filemap.c is not
> very verbose at all.
There's sendfile manpage in new netman package managed by Andi Kleen. They can
be found on ftp.muc.de/people/ak/
> Do I need to use glibc to use sendfile()?
No, you can call it via syscall4 macro:
#include <asm/types.h>
#include <asm/unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
int main(void) {
int fdo=0,fdi=0;
int size=0;
off_t offset=0;
int retval;
...
retval=sendfile(fdo,fdi,&offset,size);
...
}
_syscall4(ssize_t,sendfile,int,fdo,int,fdi,off_t,off,size_t,size);
BTW has anynone tried to actually use sendfile() in real world? I.e. in
Apache or other daemons that tend to transfer big amounts of data.
--
Pawel Krawczyk, CETI internet, Krakow. http://www.ceti.com.pl/
Johnny Teveßen
> _syscall4(ssize_t,sendfile,int,fdo,int,fdi,off_t,off,size_t,size);
Shouldn't this be:
_syscall4(ssize_t,sendfile,int,fdo,int,fdi,off_t*,off,size_t,size)
?
johnny
Felix von Leitner
> BTW has anynone tried to actually use sendfile() in real world? I.e. in
> Apache or other daemons that tend to transfer big amounts of data.
To be honest, I don't understand why anyone would want to use it.
If I use sendfile, I need to open a new process/thread for every
connection, right? OK, apache already does that, but that eats more
resources than a single-threaded select based server, doesn't it?
It is probably a big win for FTP servers who tend to be multi-process
anyway.
Does anyone have an example for the CORK option mentioned in the man
page from Andy? I do not really understand it, especially why it is
recommended in conjunction with sendfile. Sound's like a win for a web
server that uses write() to write the header line by line, buy maybe I
completely misunderstood that option.
Felix
Linus Torvalds
Felix von Leitner <lei...@math.fu-berlin.de> wrote:
>Thus spake Pawel Krawczyk (krav...@tau.ceti.com.pl):
>> BTW has anynone tried to actually use sendfile() in real world? I.e. in
>> Apache or other daemons that tend to transfer big amounts of data.
>
>To be honest, I don't understand why anyone would want to use it.
>If I use sendfile, I need to open a new process/thread for every
>connection, right?
No. sendfile() was designed to do the right thing wrt nonblocking
writes, so you can have a select() loop with sendfile() the same way
you'd have it with read()+write().
Linus
Matti Aarnio
> Thus spake Pawel Krawczyk (krav...@tau.ceti.com.pl):
> > BTW has anynone tried to actually use sendfile() in real world? I.e. in
> > Apache or other daemons that tend to transfer big amounts of data.
>
> To be honest, I don't understand why anyone would want to use it.
> If I use sendfile, I need to open a new process/thread for every
> resources than a single-threaded select based server, doesn't it?
>
> It is probably a big win for FTP servers who tend to be multi-process
> anyway.
Indeed. Last week a collegue of mine was amazed when he heard
that ftpd running at ftp.cdrom.com is now using sendfile(),
and that system load dropped dramatically when that change was
made in there -- it is a FreeBSD system.
There were other Linux/BSD comparison presented too, but that
week was spent at Orlando/IETF, not at Boston (or where ever
the LISA'98 was held..)
....
> Felix
/Matti Aarnio <matti....@sonera.fi>
Chip Salzenberg
> No. sendfile() was designed to do the right thing wrt nonblocking
> writes, so you can have a select() loop with sendfile() the same way
> you'd have it with read()+write().
Would you mean "the right thing wrt nonblocking _reads_", by any chance?
--
Chip Salzenberg - a.k.a. - <ch...@perlsupport.com>
"When do you work?" "Whenever I'm not busy."
Linus Torvalds
On Wed, 16 Dec 1998, Chip Salzenberg wrote:
> According to Linus Torvalds:
> > No. sendfile() was designed to do the right thing wrt nonblocking
> > writes, so you can have a select() loop with sendfile() the same way
> > you'd have it with read()+write().
>
> Would you mean "the right thing wrt nonblocking _reads_", by any chance?
Nope, sendfile() always reads from the page cache, so the reads are never
non-blocking. Obviously for a web server you'd do non-blocking reads too
(to get the commands from the client), but sendfile() itself is not
implicated in that end..
Linus
Felix von Leitner
> >To be honest, I don't understand why anyone would want to use it.
> >If I use sendfile, I need to open a new process/thread for every
> >connection, right?
> writes, so you can have a select() loop with sendfile() the same way
> you'd have it with read()+write().
Sorry, I do not understand that.
If I use sendfile with nonblocking writes, there is no gain compared to
using read+write except that I don't need a buffer.
I would see the value of sendfile if I could just use sendfile and then
select on writing and it would only return when all the bytes have been
transferred. Now, _that_ would be great ;)
The reason to use sendfile would be to save the context switches, so I
don't want my select to return all the time, right?
Felix
Todd Graham Lewis
> The reason to use sendfile would be to save the context switches, so I
> don't want my select to return all the time, right?
I don't know that sendfile is so much intended to save context switches
as it is to obviate unnecessary copying from kernal space to user space
and back down to the kernel again. Someone correct me if I'm wrong.
--
Todd Graham Lewis tle...@mindspring.net (800) 719-4664, x2804
"It's still ludicrous that nobody's ever made a run at us by making UNIX
a popular platform on PCs. It's almost too late now." -- Steve Balmer
"It is too late." -- Bill Gates _Newsweek_, 6/23/97, p. 82
Felix von Leitner
> > The reason to use sendfile would be to save the context switches, so I
> > don't want my select to return all the time, right?
> I don't know that sendfile is so much intended to save context switches
> as it is to obviate unnecessary copying from kernal space to user space
> and back down to the kernel again. Someone correct me if I'm wrong.
Well, if you wanted to save that copying, you could simply write from the
mmap()ed file and would not need sendfile, too. And I believe that
sendfile does just that, anyway ;)
Felix