tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposal to obsolete SYS_pipe



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



Home | Main Index | Thread Index | Old Index