linux-kernel - Is splice() useful without page stealing?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <23986fd90912171847w6d46ba2bx9d8763a63fc758c3@mail.gmail.com>
Date:	Thu, 17 Dec 2009 18:47:19 -0800
From:	"Patrick J. LoPresti" <lopresti@...il.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Is splice() useful without page stealing?

I just spent a couple of hours tracking down documentation and
discussion on splice().  I apologize in advance if I missed something.

As near as I can tell, SPLICE_F_MOVE (aka. "page stealing") was
removed in 2.6.21
(http://lkml.indiana.edu/hypermail/linux/kernel/0703.1/2592.html) and
never reinstated.

My question is, doesn't this make splice() nearly useless from a
performance perspective?

For example, consider implementing a simple file copy.  You might
argue that even without SPLICE_F_MOVE, splice() can be used to avoid
one copy of the data:  The standard/portable "read() into a user
buffer and write() from that buffer" is two copies, whereas splice()
to and from a pipe would be one copy.

But that argument is bogus, because modern processors have sizable
caches.  If you simply write the portable code to read() into a small
buffer (16K or so) and write() from that buffer, and you use the same
buffer over and over, the data in the buffer should get overwritten in
the L1 cache before it ever gets flushed to the RAM behind it.  In
effect, this simple loop would move data into the L1 cache (on read())
and then back into the page cache (on write()), for a net of ONE
round-trip to physical memory.

Similarly for copying data from a socket to a file in an attempt to
implement "recvfile()".

Now, if splice() actually let you do things like flip pages from the
network stack into the page cache with zero copies, then I could see
the point.  As it is, I am curious to know:

1) Does anybody have any actual benchmarks showing performance
advantages for splice() over read()/write()?   If so, can I obtain the
benchmark code?

2) Are there any plans to reinstate SPLICE_F_MOVE or something equivalent?

Thank you.

 - Pat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/