From: Mark Mielke <mark@mark.mielke.cc>
To: Chris Friesen <cfriesen@nortelnetworks.com>
Cc: "Pål Halvorsen" <paalh@ifi.uio.no>, "bert hubert" <ahu@ds9a.nl>,
linux-kernel@vger.kernel.org
Subject: Re: sendfile
Date: Fri, 2 May 2003 17:06:48 -0400 [thread overview]
Message-ID: <20030502210648.GA5322@mark.mielke.cc> (raw)
In-Reply-To: <3EB1F1CD.4060702@nortelnetworks.com>
On Fri, May 02, 2003 at 12:19:25AM -0400, Chris Friesen wrote:
> According to this:
> http://asia.cnet.com/builder/program/dev/0,39009360,39062783,00.htm
> using sendfile() is easier on the CPU due to less trashing of the TLB.
Thanks for the link. It looks quite accurate.
One question it raises in my mind, is whether there would be value in
improving write()/send() such that they detect that the userspace
pointer refers entirely to mmap()'d file pages, and therefore no copy
of data from userspace -> kernelspace should be performed. The pages
could be loaded and accessed directly (as they are with sendfile())
rather than generating a page fault to load the pages. The TLB trashing
does not need to occur.
I guess the first response to this question would be 'why not use
sendfile()? it already exists, and people have already begun to use
it...'
My answer is that I don't like sendfile(). It is not-yet-standard, and
is fairly limited. I could just be naive, but I think that:
write(fd, mmapped_file_pages, length);
Could be transparently mapped to the sendfile() code in the kernel,
minimizing the benefit of sendfile() having its own system call. It all
comes down to optimization. The current implementation of mmap() is not
optimal where mmap()'d file pages are passed as data to system calls.
mark
--
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
next prev parent reply other threads:[~2003-05-02 20:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-30 14:28 sendfile Pål Halvorsen
2003-04-30 16:51 ` sendfile bert hubert
2003-04-30 19:12 ` sendfile Pål Halvorsen
2003-04-30 19:28 ` sendfile bert hubert
2003-04-30 21:57 ` sendfile Pål Halvorsen
2003-04-30 22:18 ` sendfile Mark Mielke
2003-04-30 22:34 ` sendfile Pål Halvorsen
2003-05-01 4:28 ` sendfile Mark Mielke
2003-05-01 15:25 ` sendfile Joseph Malicki
2003-05-01 21:17 ` sendfile Pål Halvorsen
2003-05-01 22:31 ` sendfile Chris Friesen
2003-05-01 23:32 ` sendfile Ketil Froyn
2003-05-02 9:02 ` sendfile Bernd Eckenfels
2003-05-02 2:41 ` sendfile Mark Mielke
2003-05-02 4:19 ` sendfile Chris Friesen
2003-05-02 21:06 ` Mark Mielke [this message]
2003-05-03 0:42 ` sendfile Miquel van Smoorenburg
2003-05-03 15:04 ` sendfile Mark Mielke
2003-05-03 12:52 ` sendfile Pål Halvorsen
2003-05-03 21:01 ` sendfile Pål Halvorsen
2003-05-04 0:53 ` sendfile Miquel van Smoorenburg
-- strict thread matches above, loose matches on Subject: below --
2001-05-24 8:44 sendfile Pål Halvorsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030502210648.GA5322@mark.mielke.cc \
--to=mark@mark.mielke.cc \
--cc=ahu@ds9a.nl \
--cc=cfriesen@nortelnetworks.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paalh@ifi.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox