All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [PATCH 2/3] grant-table: refactor grant copy to reduce duplicate code
Date: Thu, 22 Jan 2015 16:04:04 +0000	[thread overview]
Message-ID: <54C12D8402000078000585B3@mail.emea.novell.com> (raw)
In-Reply-To: <54C10C57.1090406@citrix.com>

>>> On 22.01.15 at 15:42, <david.vrabel@citrix.com> wrote:
> On 22/01/15 14:24, Jan Beulich wrote:
>>>>> On 20.01.15 at 19:19, <david.vrabel@citrix.com> wrote:
>>> +static int gnttab_copy_buf(const struct gnttab_copy *op,
>>> +                           struct gnttab_copy_buf *dest,
>>> +                           const struct gnttab_copy_buf *src)
>>> +{
>>> +    s16 rc;
>> 
>> An s16 local variable used as return value in a function returning
>> int is kind of odd. Elsewhere there are also cases where the
>> function return types are also s16. I don't think that's particularly
>> efficient, and hence I think it should be changed in the places
>> where you add new helpers even if the original code used s16
>> for that purpose.
> 
> I was (trying to) use s16 where we return a GNTST_* value instead of the
> usual -ERRNO.  I can change them all to int if this is preferred
> (although I not sure I get your efficiency argument).

Operations on 16-bit registers are less efficient on x86 (due to
the extra operand size prefix byte). On ARM I don't even know
how they get carried out by the compiler, but there surely is no
way to access the low 16 bits of a register by other than
memory loads or stores.

Jan

  reply	other threads:[~2015-01-22 16:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-20 18:19 [PATCHv2 0/3] grant-table: optimize grant copies when crossing page boundaries David Vrabel
2015-01-20 18:19 ` [PATCH 1/3] grant-table: use uint16_t consistently for grant copy offset and length David Vrabel
2015-01-22 14:24   ` Jan Beulich
2015-01-20 18:19 ` [PATCH 2/3] grant-table: refactor grant copy to reduce duplicate code David Vrabel
2015-01-22 14:24   ` Jan Beulich
2015-01-22 14:42     ` David Vrabel
2015-01-22 16:04       ` Jan Beulich [this message]
2015-01-22 16:28   ` Tim Deegan
2015-01-20 18:19 ` [PATCH 3/3] grant-table: defer releasing pages acquired in a grant copy David Vrabel
2015-01-22 14:34   ` Jan Beulich
2015-01-22 14:39     ` David Vrabel
2015-01-22 16:01       ` Jan Beulich
2015-01-22 16:33   ` Tim Deegan
2015-01-23 10:43 [PATCHv3 0/3] grant-table: optimize grant copies when crossing page boundaries David Vrabel
2015-01-23 10:43 ` [PATCH 2/3] grant-table: refactor grant copy to reduce duplicate code David Vrabel
2015-01-23 16:26   ` Jan Beulich
2015-01-29 11:02   ` Tim Deegan

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=54C12D8402000078000585B3@mail.emea.novell.com \
    --to=jbeulich@suse.com \
    --cc=david.vrabel@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.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.