From: Rob Gardner <rob.gardner@oracle.com>
To: sparclinux@vger.kernel.org
Subject: Re: [PATCH 1/2] sparc64: Ensure perf can access user stacks
Date: Sat, 26 Dec 2015 22:25:55 +0000 [thread overview]
Message-ID: <567F13F3.6040705@oracle.com> (raw)
In-Reply-To: <1450844167-7327-1-git-send-email-rob.gardner@oracle.com>
On 12/25/2015 11:27 PM, David Miller wrote:
> From: Rob Gardner <rob.gardner@oracle.com>
> Date: Fri, 25 Dec 2015 22:02:43 -0700
>
>> Also, in the code we submitted, there was an optimization in which
>> %asi is read, and then only set to ASI_AIUS if necessary. This
>> drastically reduces the number of writes to the %asi register since
>> most of the time %asi will contain ASI_AIUS. This seems like a
>> reasonable optimization, since this function may be called thousands
>> of times per second on every cpu.
> I noticed the optimization.
>
> If this was happening for every memcpy call, I'd say it's worth it.
>
> But it's happening once for a series of memcpy/copy_from_user_inatomic()
> calls so I'd say it's not really worth it.
>
> So unless you can show me how the current version fails, I'm keeping it
> as-is because either we should consistently use set_fs/get_fs in C
> code rather than open coded inline asm, or we should create a well
> documented set of helper functions for this specific situation and
> _ALSO_ use it elsewhere where the same problems exist such as some
> of the uses of set_fs/get_fs in process_64.c
>
Fair enough. You've convinced me that my worries are unfounded. Let's
consider the matter settled. Thanks.
Rob
prev parent reply other threads:[~2015-12-26 22:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-23 4:16 [PATCH 1/2] sparc64: Ensure perf can access user stacks Rob Gardner
2015-12-23 5:45 ` David Miller
2015-12-24 16:43 ` David Miller
2015-12-24 17:39 ` Rob Gardner
2015-12-26 4:25 ` David Miller
2015-12-26 5:02 ` Rob Gardner
2015-12-26 6:27 ` David Miller
2015-12-26 22:25 ` Rob Gardner [this message]
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=567F13F3.6040705@oracle.com \
--to=rob.gardner@oracle.com \
--cc=sparclinux@vger.kernel.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.