From: Nicholas Piggin <npiggin@gmail.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
Rich Felker <dalias@libc.org>
Cc: libc-alpha@sourceware.org, libc-dev@lists.llvm.org,
linuxppc-dev@lists.ozlabs.org, musl@lists.openwall.com
Subject: Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
Date: Mon, 20 Apr 2020 10:46:45 +1000 [thread overview]
Message-ID: <1587342668.1krc7b5v5v.astroid@bobo.none> (raw)
In-Reply-To: <65f70b10-bfc1-e9f6-d48a-4b063ad6b669@linaro.org>
Excerpts from Adhemerval Zanella's message of April 17, 2020 4:52 am:
>
>
> On 16/04/2020 15:31, Rich Felker wrote:
>> On Thu, Apr 16, 2020 at 03:18:42PM -0300, Adhemerval Zanella wrote:
>>>
>>>
>>> On 16/04/2020 14:59, Rich Felker wrote:
>>>> On Thu, Apr 16, 2020 at 02:50:18PM -0300, Adhemerval Zanella wrote:
>>>>>
>>>>>
>>>>> On 16/04/2020 12:37, Rich Felker wrote:
>>>>>> On Thu, Apr 16, 2020 at 11:16:04AM -0300, Adhemerval Zanella wrote:
>>>>>>>> My preference would be that it work just like the i386 AT_SYSINFO
>>>>>>>> where you just replace "int $128" with "call *%%gs:16" and the kernel
>>>>>>>> provides a stub in the vdso that performs either scv or the old
>>>>>>>> mechanism with the same calling convention. Then if the kernel doesn't
>>>>>>>> provide it (because the kernel is too old) libc would have to provide
>>>>>>>> its own stub that uses the legacy method and matches the calling
>>>>>>>> convention of the one the kernel is expected to provide.
>>>>>>>
>>>>>>> What about pthread cancellation and the requirement of checking the
>>>>>>> cancellable syscall anchors in asynchronous cancellation? My plan is
>>>>>>> still to use musl strategy on glibc (BZ#12683) and for i686 it
>>>>>>> requires to always use old int$128 for program that uses cancellation
>>>>>>> (static case) or just threads (dynamic mode, which should be more
>>>>>>> common on glibc).
>>>>>>>
>>>>>>> Using the i686 strategy of a vDSO bridge symbol would require to always
>>>>>>> fallback to 'sc' to still use the same cancellation strategy (and
>>>>>>> thus defeating this optimization in such cases).
>>>>>>
>>>>>> Yes, I assumed it would be the same, ignoring the new syscall
>>>>>> mechanism for cancellable syscalls. While there are some exceptions,
>>>>>> cancellable syscalls are generally not hot paths but things that are
>>>>>> expected to block and to have significant amounts of work to do in
>>>>>> kernelspace, so saving a few tens of cycles is rather pointless.
>>>>>>
>>>>>> It's possible to do a branch/multiple versions of the syscall asm for
>>>>>> cancellation but would require extending the cancellation handler to
>>>>>> support checking against multiple independent address ranges or using
>>>>>> some alternate markup of them.
>>>>>
>>>>> The main issue is at least for glibc dynamic linking is way more common
>>>>> than static linking and once the program become multithread the fallback
>>>>> will be always used.
>>>>
>>>> I'm not relying on static linking optimizing out the cancellable
>>>> version. I'm talking about how cancellable syscalls are pretty much
>>>> all "heavy" operations to begin with where a few tens of cycles are in
>>>> the realm of "measurement noise" relative to the dominating time
>>>> costs.
>>>
>>> Yes I am aware, but at same time I am not sure how it plays on real world.
>>> For instance, some workloads might issue kernel query syscalls, such as
>>> recv, where buffer copying might not be dominant factor. So I see that if
>>> the idea is optimizing syscall mechanism, we should try to leverage it
>>> as whole in libc.
>>
>> Have you timed a minimal recv? I'm not assuming buffer copying is the
>> dominant factor. I'm assuming the overhead of all the kernel layers
>> involved is dominant.
>
> Not really, but reading the advantages of using 'scv' over 'sc' also does
> not outline the real expect gain. Taking in consideration this should
> be a micro-optimization (focused on entry syscall patch), I think we should
> use where it possible.
It's around 90 cycles improvement, depending on config options and
speculative mitigations in place, this may be roughly 5-20% of a gettid
syscall, which itself probably bears little relationship to what a recv
syscall doing real work would do, it's easy to swamp it with other work.
But it's a pretty big win in terms of how much we try to optimise this
path.
Thanks,
Nick
next prev parent reply other threads:[~2020-04-20 0:48 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 21:45 Nicholas Piggin
2020-04-15 22:55 ` [musl] " Rich Felker
2020-04-16 0:16 ` Nicholas Piggin
2020-04-16 0:48 ` Rich Felker
2020-04-16 2:24 ` Nicholas Piggin
2020-04-16 2:35 ` Rich Felker
2020-04-16 2:53 ` Nicholas Piggin
2020-04-16 3:03 ` Rich Felker
2020-04-16 3:41 ` Nicholas Piggin
2020-04-16 20:18 ` Florian Weimer
2020-04-16 9:58 ` Szabolcs Nagy
2020-04-20 0:27 ` Nicholas Piggin
2020-04-20 1:29 ` Rich Felker
2020-04-20 2:08 ` Nicholas Piggin
2020-04-20 21:17 ` Szabolcs Nagy
2020-04-21 9:57 ` Florian Weimer
2020-04-16 15:21 ` Jeffrey Walton
2020-04-16 15:40 ` Rich Felker
2020-04-16 4:48 ` Florian Weimer
2020-04-16 15:35 ` Rich Felker
2020-04-16 16:42 ` Florian Weimer
2020-04-16 16:52 ` Rich Felker
2020-04-16 18:12 ` Florian Weimer
2020-04-16 23:02 ` Segher Boessenkool
2020-04-17 0:34 ` Rich Felker
2020-04-17 1:48 ` Segher Boessenkool
2020-04-17 8:34 ` Florian Weimer
2020-04-16 14:16 ` Adhemerval Zanella
2020-04-16 15:37 ` Rich Felker
2020-04-16 17:50 ` Adhemerval Zanella
2020-04-16 17:59 ` Rich Felker
2020-04-16 18:18 ` Adhemerval Zanella
2020-04-16 18:31 ` Rich Felker
2020-04-16 18:44 ` Rich Felker
2020-04-16 18:52 ` Adhemerval Zanella
2020-04-20 0:46 ` Nicholas Piggin [this message]
2020-04-20 1:10 ` Nicholas Piggin
2020-04-20 1:34 ` Rich Felker
2020-04-20 2:32 ` Nicholas Piggin
2020-04-20 4:09 ` Rich Felker
2020-04-20 4:31 ` Nicholas Piggin
2020-04-20 17:27 ` Rich Felker
2020-04-22 6:18 ` Nicholas Piggin
2020-04-22 6:29 ` Nicholas Piggin
2020-04-23 2:36 ` Rich Felker
2020-04-23 12:13 ` Adhemerval Zanella
2020-04-23 16:18 ` Rich Felker
2020-04-23 16:35 ` Adhemerval Zanella
2020-04-23 16:43 ` Rich Felker
2020-04-23 17:15 ` Adhemerval Zanella
2020-04-23 17:42 ` Rich Felker
2020-04-25 3:40 ` Nicholas Piggin
2020-04-25 4:52 ` Rich Felker
2020-04-25 3:30 ` Nicholas Piggin
2020-04-21 12:28 ` David Laight
2020-04-21 14:39 ` Rich Felker
2020-04-21 15:00 ` Adhemerval Zanella
2020-04-21 15:31 ` David Laight
2020-04-22 6:54 ` Nicholas Piggin
2020-04-22 7:15 ` [musl] " Florian Weimer
2020-04-22 7:31 ` Nicholas Piggin
2020-04-22 8:11 ` Florian Weimer
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=1587342668.1krc7b5v5v.astroid@bobo.none \
--to=npiggin@gmail.com \
--cc=adhemerval.zanella@linaro.org \
--cc=dalias@libc.org \
--cc=libc-alpha@sourceware.org \
--cc=libc-dev@lists.llvm.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=musl@lists.openwall.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).