[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20160525.132145.1271448744307448631.davem@davemloft.net>
Date: Wed, 25 May 2016 13:21:45 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: ynorov@...iumnetworks.com
Cc: arnd@...db.de, catalin.marinas@....com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, linux-arch@...r.kernel.org,
linux-s390@...r.kernel.org, libc-alpha@...rceware.org,
schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
pinskia@...il.com, broonie@...nel.org, joseph@...esourcery.com,
christoph.muellner@...obroma-systems.com,
bamvor.zhangjian@...wei.com, szabolcs.nagy@....com,
klimov.linux@...il.com, Nathan_Lynch@...tor.com, agraf@...e.de,
Prasun.Kapoor@...iumnetworks.com, kilobyte@...band.pl,
geert@...ux-m68k.org, philipp.tomsich@...obroma-systems.com
Subject: Re: [PATCH 01/23] all: syscall wrappers: add documentation
From: Yury Norov <ynorov@...iumnetworks.com>
Date: Wed, 25 May 2016 23:03:27 +0300
> On Wed, May 25, 2016 at 12:30:17PM -0700, David Miller wrote:
>> From: Yury Norov <ynorov@...iumnetworks.com>
>> Date: Tue, 24 May 2016 03:04:30 +0300
>>
>> > +To clear that top halves, automatic wrappers are introduced. They clear all
>> > +required registers before passing control to regular syscall handler.
>>
>> Why have one of these for every single compat system call, rather than
>> simply clearing the top half of all of these registers unconditionally
>> in the 32-bit system call trap before the system call is invoked?
>>
>> That's what we do on sparc64.
>>
>> And with that, you only need wrappers for the case where there needs
>> to be proper sign extention of a 32-bit signed argument.
>
> It was discussed as one of possible solutions. The downside of it is
> that we cannot pass 64-bit types (like off_t) in single register.
Wrappers can be added for the cases where you'd like to do that.
> The other downside is that we clear top halves for every single
> syscall, and it looks excessive. So, from spark64 and s390 approaches
> we choosed second.
It's like 4 cpu cycles even on crappy sparc64 cpus which only dual
issue. :)
And that's a pretty low cost for the benefits if you ask me.
Powered by blists - more mailing lists