From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Cc: "linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Andrei Vagin <avagin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>,
Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>,
Linux Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Pavel Emelyanov <xemul-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>,
Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Cyrill Gorcunov
<gorcunov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,
Michael Kerrisk
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Willy Tarreau <w@1wt.eu>,
Andrey Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Subject: Re: Simplfying copy_siginfo_to_user
Date: Mon, 24 Jul 2017 14:01:59 -0500 [thread overview]
Message-ID: <87r2x54q1k.fsf@xmission.com> (raw)
In-Reply-To: <CA+55aFyH5W2doo9vxXta_-pXfNXqQ19d7z48k1hmfAot+aJvMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> (Linus Torvalds's message of "Mon, 24 Jul 2017 10:43:34 -0700")
Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> writes:
> On Sat, Jul 22, 2017 at 1:25 PM, Eric W. Biederman
> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>> I played with some clever changes such as limiting the copy to 48 bytes,
>> disabling the memset and the like but I could not get a strong enough
>> signal to say that any one change removed the extra or a clear part of
>> it 20ns.
>
> What CPU did you use? Because the SMAP bit in particular matters.
>
> The field-by-field copies are extremely slow on modern CPU's that
> implement SMAP, unless you also use the special "unsafe_put_user()"
> code (or the nasty old put_user_ex() code that some of the x86 signal
> code uses).
>
> So one of the advantages of just copy_to_user() ends up being visible
> only on Broadwell+ (or whatever the SMAP cutoff is).
Good point.
The cpu I was testing on was an AMD A10. I don't actually have a cpu
that supports SMAP handy.
If you would like I can post the minimal patches and benckmark so anyone
who is interested could reproduce this for themselves.
I suspect that if it is down to only 20ns without SMAP this will
definitely be a performance improvement in the presence of SMAP.
Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Oleg Nesterov <oleg@redhat.com>,
Andrei Vagin <avagin@virtuozzo.com>,
Thomas Gleixner <tglx@linutronix.de>, Greg KH <greg@kroah.com>,
Andrey Vagin <avagin@openvz.org>, Serge Hallyn <serge@hallyn.com>,
Pavel Emelyanov <xemul@virtuozzo.com>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Peter Zijlstra <peterz@infradead.org>, Willy Tarreau <w@1wt.eu>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Linux Containers <containers@lists.linux-foundation.org>,
Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: Simplfying copy_siginfo_to_user
Date: Mon, 24 Jul 2017 14:01:59 -0500 [thread overview]
Message-ID: <87r2x54q1k.fsf@xmission.com> (raw)
Message-ID: <20170724190159.lCQvq8n362zG0sKQo96CiZUrXaZFsWJ4x_qm3LsXtak@z> (raw)
In-Reply-To: <CA+55aFyH5W2doo9vxXta_-pXfNXqQ19d7z48k1hmfAot+aJvMw@mail.gmail.com> (Linus Torvalds's message of "Mon, 24 Jul 2017 10:43:34 -0700")
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, Jul 22, 2017 at 1:25 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> I played with some clever changes such as limiting the copy to 48 bytes,
>> disabling the memset and the like but I could not get a strong enough
>> signal to say that any one change removed the extra or a clear part of
>> it 20ns.
>
> What CPU did you use? Because the SMAP bit in particular matters.
>
> The field-by-field copies are extremely slow on modern CPU's that
> implement SMAP, unless you also use the special "unsafe_put_user()"
> code (or the nasty old put_user_ex() code that some of the x86 signal
> code uses).
>
> So one of the advantages of just copy_to_user() ends up being visible
> only on Broadwell+ (or whatever the SMAP cutoff is).
Good point.
The cpu I was testing on was an AMD A10. I don't actually have a cpu
that supports SMAP handy.
If you would like I can post the minimal patches and benckmark so anyone
who is interested could reproduce this for themselves.
I suspect that if it is down to only 20ns without SMAP this will
definitely be a performance improvement in the presence of SMAP.
Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Oleg Nesterov <oleg@redhat.com>,
Andrei Vagin <avagin@virtuozzo.com>,
Thomas Gleixner <tglx@linutronix.de>, Greg KH <greg@kroah.com>,
Andrey Vagin <avagin@openvz.org>, Serge Hallyn <serge@hallyn.com>,
Pavel Emelyanov <xemul@virtuozzo.com>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Peter Zijlstra <peterz@infradead.org>, Willy Tarreau <w@1wt.eu>,
"linux-arch\@vger.kernel.org" <linux-arch@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Linux Containers <containers@lists.linux-foundation.org>,
Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: Simplfying copy_siginfo_to_user
Date: Mon, 24 Jul 2017 14:01:59 -0500 [thread overview]
Message-ID: <87r2x54q1k.fsf@xmission.com> (raw)
In-Reply-To: <CA+55aFyH5W2doo9vxXta_-pXfNXqQ19d7z48k1hmfAot+aJvMw@mail.gmail.com> (Linus Torvalds's message of "Mon, 24 Jul 2017 10:43:34 -0700")
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, Jul 22, 2017 at 1:25 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> I played with some clever changes such as limiting the copy to 48 bytes,
>> disabling the memset and the like but I could not get a strong enough
>> signal to say that any one change removed the extra or a clear part of
>> it 20ns.
>
> What CPU did you use? Because the SMAP bit in particular matters.
>
> The field-by-field copies are extremely slow on modern CPU's that
> implement SMAP, unless you also use the special "unsafe_put_user()"
> code (or the nasty old put_user_ex() code that some of the x86 signal
> code uses).
>
> So one of the advantages of just copy_to_user() ends up being visible
> only on Broadwell+ (or whatever the SMAP cutoff is).
Good point.
The cpu I was testing on was an AMD A10. I don't actually have a cpu
that supports SMAP handy.
If you would like I can post the minimal patches and benckmark so anyone
who is interested could reproduce this for themselves.
I suspect that if it is down to only 20ns without SMAP this will
definitely be a performance improvement in the presence of SMAP.
Eric
next prev parent reply other threads:[~2017-07-24 19:01 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87lgot2loq.fsf@xmission.com>
[not found] ` <87zid90vye.fsf_-_@xmission.com>
[not found] ` <20170615225426.GP31671@ZenIV.linux.org.uk>
[not found] ` <87poe4zrs1.fsf@xmission.com>
[not found] ` <CA+55aFxpv+gchzs7AYgSC8feAOV=B6mjFgBVm4Kx+83J2CNE-w@mail.gmail.com>
[not found] ` <87poe3vsa9.fsf@xmission.com>
[not found] ` <CALCETrX=SquyR8JZqHDNx=_FQKQo-0u9AxfdUwJs_hujVO2A-g@mail.gmail.com>
[not found] ` <87h8zfua59.fsf@xmission.com>
[not found] ` <CALCETrWPBn31Dye=81r2ZMainNOnDy5c_QxbU2uRjnJs0ie=Zg@mail.gmail.com>
[not found] ` <87r2yjsuwl.fsf@xmission.com>
[not found] ` <20170616191602.GA10675@1wt.eu>
2017-06-30 12:36 ` [PATCH 0/8] signal: Fix sending signals with siginfo Eric W. Biederman
2017-06-30 12:36 ` Eric W. Biederman
2017-07-18 14:04 ` [PATCH v2 0/7] " Eric W. Biederman
2017-07-18 14:04 ` Eric W. Biederman
2017-07-18 14:06 ` [PATCH 1/7] signal/alpha: Document a conflict with SI_USER for SIGTRAP Eric W. Biederman
2017-07-18 14:06 ` Eric W. Biederman
[not found] ` <20170718140651.15973-1-ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-18 18:22 ` Richard Henderson
2017-07-18 18:22 ` Richard Henderson
2017-07-18 14:06 ` [PATCH 4/7] signal/mips: Document a conflict with SI_USER with SIGFPE Eric W. Biederman
2017-08-07 16:18 ` Maciej W. Rozycki
2017-08-07 16:18 ` Maciej W. Rozycki
2017-08-07 17:41 ` Linus Torvalds
[not found] ` <CA+55aFx3ss90b4x2bo4si80kQUjMVL1zUX3Oxvu04OE14nUtFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-08-07 19:55 ` Ralf Baechle
2017-08-07 19:55 ` Ralf Baechle
[not found] ` <alpine.DEB.2.00.1708071706290.17596-AURtyoD2VtPP6B53oEZunQ@public.gmane.org>
2017-08-07 17:41 ` Linus Torvalds
2017-08-08 15:29 ` Eric W. Biederman
2017-08-08 15:29 ` Eric W. Biederman
2017-08-08 15:29 ` Eric W. Biederman
[not found] ` <87mv7agjsh.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-08-08 23:19 ` Maciej W. Rozycki
2017-08-08 23:19 ` Maciej W. Rozycki
2017-08-08 23:19 ` Maciej W. Rozycki
[not found] ` <20170718140651.15973-4-ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-08-07 16:18 ` Maciej W. Rozycki
[not found] ` <87o9shg7t7.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-18 14:06 ` [PATCH 1/7] signal/alpha: Document a conflict with SI_USER for SIGTRAP Eric W. Biederman
2017-07-18 14:06 ` [PATCH 2/7] signal/ia64: Document a conflict with SI_USER with SIGFPE Eric W. Biederman
2017-07-18 14:06 ` Eric W. Biederman
2017-07-18 14:06 ` Eric W. Biederman
2017-07-18 14:06 ` [PATCH 3/7] signal/sparc: " Eric W. Biederman
2017-07-18 14:06 ` Eric W. Biederman
2017-07-18 14:06 ` Eric W. Biederman
2017-07-18 14:06 ` [PATCH 4/7] signal/mips: " Eric W. Biederman
2017-07-18 14:06 ` [PATCH 5/7] signal/testing: Don't look for __SI_FAULT in userspace Eric W. Biederman
2017-07-18 14:06 ` Eric W. Biederman
2017-07-18 14:06 ` [PATCH 6/7] fcntl: Don't use ambiguous SIG_POLL si_codes Eric W. Biederman
2017-07-18 14:06 ` Eric W. Biederman
[not found] ` <20170718140651.15973-6-ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-20 16:16 ` Oleg Nesterov
2017-07-20 16:16 ` Oleg Nesterov
2017-07-21 2:33 ` Eric W. Biederman
[not found] ` <20170720161603.GA14430-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-07-21 2:33 ` Eric W. Biederman
2017-07-18 14:06 ` [PATCH 7/7] signal: Remove kernel interal si_code magic Eric W. Biederman
2017-07-18 14:06 ` Eric W. Biederman
[not found] ` <20170718140651.15973-7-ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-18 16:57 ` Linus Torvalds
2017-07-18 16:57 ` Linus Torvalds
2017-07-18 16:57 ` Linus Torvalds
[not found] ` <CA+55aFyKsmf+BpYjcH30MGpHTDJ=zgYPx6kwyEB9CXXFxj_xsw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-07-18 17:27 ` Eric W. Biederman
2017-07-18 17:27 ` Eric W. Biederman
2017-07-18 17:27 ` Eric W. Biederman
[not found] ` <878tjlbqpt.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-22 20:25 ` Simplfying copy_siginfo_to_user Eric W. Biederman
2017-07-22 20:25 ` Eric W. Biederman
2017-07-22 20:25 ` Eric W. Biederman
[not found] ` <8760ek5ics.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-24 17:43 ` Linus Torvalds
2017-07-24 17:43 ` Linus Torvalds
2017-07-25 1:37 ` Al Viro
[not found] ` <20170725013756.GH2063-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2017-07-31 16:37 ` Eric W. Biederman
2017-07-31 16:37 ` Eric W. Biederman
2017-07-31 16:37 ` Eric W. Biederman
[not found] ` <CA+55aFyH5W2doo9vxXta_-pXfNXqQ19d7z48k1hmfAot+aJvMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-07-24 19:01 ` Eric W. Biederman [this message]
2017-07-24 19:01 ` Eric W. Biederman
2017-07-24 19:01 ` Eric W. Biederman
2017-07-25 1:37 ` Al Viro
[not found] ` <87bmp5y7nj.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-18 14:04 ` [PATCH v2 0/7] signal: Fix sending signals with siginfo Eric W. Biederman
[not found] ` <20170616191602.GA10675-K+wRfnb2/UA@public.gmane.org>
2017-06-30 12:36 ` [PATCH 0/8] " Eric W. Biederman
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=87r2x54q1k.fsf@xmission.com \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=avagin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org \
--cc=avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=gorcunov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
--cc=w@1wt.eu \
--cc=xemul-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.