mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@bonn-fries.net>
To: Quinn Harris <quinn@nmt.edu>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: File copy system call proposal
Date: Sat, 8 Dec 2001 14:57:17 +0100	[thread overview]
Message-ID: <E16Chyk-0000zH-00@starship.berlin> (raw)
In-Reply-To: <1007782956.355.2.camel@quinn.rcn.nmt.edu> <9us387$poh$1@cesium.transmeta.com> <1007791439.355.7.camel@quinn.rcn.nmt.edu>
In-Reply-To: <1007791439.355.7.camel@quinn.rcn.nmt.edu>

On December 8, 2001 07:03 am, Quinn Harris wrote:
> On Fri, 2001-12-07 at 21:00, H. Peter Anvin wrote:
> > > Commands like cp and install open the source and destination file using
> > > the open sys call.  The data from the source is copied to the
> > > destination by repeatedly calling the read then write sys calls.  This
> > > process involves copying the data in the file from kernel memory space
> > > to the user memory space and back again.  Note that all this copying is
> > > done by the kernel upon calling read or write.  I would expect if this
> > > can be moved completely into the kernel no memory copy operations would
> > > be performed by the processor by using hardware DMA.
> > 
> > mmap(source file);
> > write(target file, mmap region);
>
> mmap will indeed get a file into user mem space without any memcopy
> operation.  But as far as I can tell from examining generic_file_write
> (in mm/filemap.c) used by ext2 and I asume many others, a write will
> copy the memory even if it was mapped via mmap.  Am I missing
> something?  This isn't true if kiobuf is used but as I understand it,
> this bypasses the buffer cache.
                    ^^^^^^---page

> I would like to see a zero-memcopy file copy.  A file copy that would
> read  the file into the buffer cache if its not already there similar to
> a normal read then write it back to disk from the cache without
> duplicating the pages.  This would probably lead to modifying the buffer
> cache to allow multiple buffer_heads to refer to the same data which
                          ^^^^^^^^^^^^---struct page
> might not be worth the overhead.
> 
> One might implement such a thing by attempting in the generic_file_read
                                   generic_file_write---^^^^^^^^^^^^^^^^^
> to determine if the memory range is an actual page or pages that can be
> eventually written to the disk without a memcopy.

There's some merit to this idea.  As Peter pointed out, an in-kernel cp isn't 
needed: mmap+write does the job.  The question is, how to avoid the 
copy_from_user and double caching of data?

Generic_file_write would have to determine that the source range is an mmap, 
then do the required xxx_get_block's (somehow) to determine the physical 
destination of the write, then finally use kio to dma the in-memory data to 
the destination.  (Never mind that get_block isn't a vfs method, that's a 
detail ;-)

The obvious problem is that, should somebody subsequently read the file, it's 
not in cache.  Oops, so much for the performance gain.  So some mechanism 
would have to be devised to get hold of the original page data by way of the 
destination inode, and to keep that consistent through the various 
combinations of events that can occur to the two files involved.  This is 
where things start to diverge quite a lot from the current page cache design, 
so if you're interested in pursuing this idea, a good way to start would be 
to find out why.

Before you put a lot of energy into it, you might consider measuring the 
actual cost of the memory copy versus the two disk transfers.

--
Daniel

  reply	other threads:[~2001-12-08 13:54 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1007833194.17577.0.camel@buffy>
2001-12-08  3:42 ` Quinn Harris
2001-12-08  4:00   ` H. Peter Anvin
2001-12-08  4:25   ` Christian Lavoie
2001-12-08  6:03   ` Quinn Harris
2001-12-08 13:57     ` Daniel Phillips [this message]
2001-12-09  0:19       ` H. Peter Anvin
2001-12-09  4:56       ` Quinn Harris
2001-12-10  5:44       ` Albert D. Cahalan
2001-12-09 20:25         ` Hans Reiser
2001-12-10 15:19         ` Daniel Phillips
2001-12-13 10:01           ` Andreas Dilger
2001-12-13 21:17             ` Pavel Machek
2001-12-19 20:26               ` Daniel Phillips
2001-12-20 10:09                 ` Pavel Machek
2001-12-20 13:38                   ` Svein Ove Aas
2001-12-20 13:53                     ` Jakob Østergaard
2001-12-20 14:00                       ` Jakob Østergaard
2001-12-23  1:19                       ` Pavel Machek
2001-12-20 14:31                     ` David Woodhouse
2001-12-20 15:06                       ` George Greer
2001-12-20 15:07                         ` David Woodhouse
2001-12-20 21:32                 ` Jamie Lokier
2001-12-08 19:23   ` Quinn Harris
2001-12-08 23:11     ` Ton Hospel
2001-12-09 15:35   ` Pavel Machek
2001-12-10 11:50     ` Albert D. Cahalan
2001-12-10  2:49       ` Hans Reiser
2001-12-10 12:13       ` Pavel Machek
2001-12-10 15:20     ` vda
2001-12-10 18:44 Petr Vandrovec

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=E16Chyk-0000zH-00@starship.berlin \
    --to=phillips@bonn-fries.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quinn@nmt.edu \
    /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

all inboxes | Powered by JetHome®