On 25.12.2017 17:18, Valery Ushakov wrote: > On Mon, Dec 25, 2017 at 16:37:43 +0100, Kamil Rytarowski wrote: > >> On 24.12.2017 22:25, Kamil Rytarowski wrote: >> >>> http://netbsd.org/~kamil/patch-00039-obsolete-SYS_pipe.txt >> >> I've extracted two patches from the above proposal. >> >> In these patches SYS_pipe is not marked COMPAT_80 and not removed from >> rump. I've left it as it is. >> >> 1. Implement pipe() with pipe2(2) in libc: >> >> New source code is now Machine Independent. >> >> http://netbsd.org/~kamil/patch-00040-implement-pipe-with-pipe2-in-libc.txt >> >> The generated code in libc for x86_64 is also simpler and shorter: >> >> 000000000008b2a2 <_pipe>: >> 8b2a2: 31 f6 xor %esi,%esi >> 8b2a4: e9 b7 f5 fa ff jmpq 3a860 <pipe2@plt> > > But you incur the price of pipe2's copyout(). I'm curious, does > anyone know how things like SMAP contribute to that price? > > I've benchmarked pipe() vs pipe2() calling the entry calls from unmodified libc. NetBSD/amd64 with SMAP and SMEP, version 8.99.7 (kernel: Nov 24th) http://netbsd.org/~kamil/pipe-bench.c pipe2() is slower than pipe() and takes 8% more time in my microbenchmarks. Therefore right, there is performance hit. How about committing the pipe.c version to libc and keep it as a fallback for archs without pipe.S? >> 2. Refactor pipe1() kernel-internal function to operate over int[2] >> rather than register_t[2]. Stop returning garbage through retval[2] >> from pipe2(2). > > Please, can you be more specific with your characterizations. > "Returning garbage" is vague, and without further details (that you do > know yourself but don't disclose) makes every reader expend time and > mental effort to figure out what are you really talking about. > > For the reference, sys_pipe2() overwrites retval[1] with the second > descriptor b/c it passes retval[] to pipe1(), like sys_pipe() does. > But what is the intended effect for pipe() causes retval[1] register > to be clobbered for pipe2(). > > > -uwe > pipe2() returns two integers (values), the 2nd one is a copy of the 2nd file descriptor that lands in fildes[2]. This is a side effect of reusing the code for sys_pipe() and not cleaning it up. The first returned value is (on success) 0. I've introduced a small refactoring that does not operate over retval[], but on an array int[2]. A user sets retval[] for pipe() when desired and needed.
Attachment:
signature.asc
Description: OpenPGP digital signature