linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ben LaHaise <bcrl@redhat.com>
To: Fabio Riccardi <fabio.riccardi@free.fr>
Cc: Rik van Riel <riel@conectiva.com.br>, linux-mm@kvack.org
Subject: Re: zero copy IO project
Date: Mon, 4 Sep 2000 21:49:56 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.21.0009042136030.23932-100000@devserv.devel.redhat.com> (raw)
In-Reply-To: <39B3FD1D.EB33427D@free.fr>

On Mon, 4 Sep 2000, Fabio Riccardi wrote:

> Hi, thanks for the pointers & explainations!
> 
> What I want is a server capable of handling high bandwidth communication and
> the kiobuf mechanisms seem to be able to do the right thing, provided that
> one rewrites the user applications accordingly...
> 
> If I understand correctly the kiobuf interface allows a user process to map a
> piece of kernel memory in its own addressing space to use as an IO buffer.
> What I originally had in mind was more something like netbsd's
> UVM: _transparent_ zero-copy IO.

> With the UVM  user applications just invokes the plain old fwrite (buff,
> ...) and the system grabs the buffer from the user space into kernel space
> without the application noticing it (the original buffer becomes TCOW in the
> application space).

Anything that requires playing VM tricks is not something you'll find a
great deal of support for amongst developers -- see the posting Linus made
against exactly this.

It comes down to complexity and the amount of gain in generic
applications.  Take apache for example.  Enabling "zero copy" through VM
tricks will buy you no benefit when it comes to the http header sent out
on a request.  But the act of transmitting a file is already well handled
by the sendfile() model.

Fwiw, there are lots of libc optimisations that are worth *more* than
"zero copy" for typical applications.  Like pre-linking libraries.  stdio
could make use of mmap for fread.

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

  reply	other threads:[~2000-09-05  1:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-04 13:39 Fabio Riccardi
2000-09-04 15:34 ` Rik van Riel
2000-09-04 19:05   ` Ben LaHaise
2000-09-04 19:50     ` Fabio Riccardi
2000-09-05  1:49       ` Ben LaHaise [this message]
2000-09-05 10:38         ` Fabio Riccardi

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=Pine.LNX.4.21.0009042136030.23932-100000@devserv.devel.redhat.com \
    --to=bcrl@redhat.com \
    --cc=fabio.riccardi@free.fr \
    --cc=linux-mm@kvack.org \
    --cc=riel@conectiva.com.br \
    /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