All of lore.kernel.org
 help / color / mirror / Atom feed
From: zhichang.yuan@linaro.org (zhichang.yuan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2] arm64: optimized copy_to_user and copy_from_user assembly code
Date: Wed, 13 Aug 2014 11:13:12 +0800	[thread overview]
Message-ID: <53EAD7C8.7070001@linaro.org> (raw)
In-Reply-To: <CAL85gmChQCM3iw-xqy-bkGRWH0jDvGf7v-GnxynS4HoOkL-cwQ@mail.gmail.com>

Hi Feng,

On 2014?08?12? 02:05, Feng Kan wrote:
> On Sun, Aug 10, 2014 at 8:01 PM, Radha Mohan <mohun106@gmail.com> wrote:
>> Hi Feng,
>>
>>
>>> +
>>> +.Lcpy_not_short:
>>> +       /*
>>> +        * We don't much care about the alignment of DST, but we want SRC
>>> +        * to be 128-bit (16 byte) aligned so that we don't cross cache line
>>> +        * boundaries on both loads and stores.
>>> +        */
>> Could you please tell why is destination alignment not an issue? Is
>> this a generic implementation that you are referring to or specific to
>> your platform?
> This is per Linaro Cortext String optimization routines.
>
> https://launchpad.net/cortex-strings
>
> Zhichang submitted something similar for the memcpy from the
> same optimization.
>
> Sorry resend in text mode.

If the both dst and src are not aligned and their alignment offset are not equal, i haven't found better way
to handle.
But it is lucky ARMv8 support the non-align memory access.
At the beginning of my patch work, i also think maybe it is more better that all load or store are aligned. I
wrote the code just like the ARMv7 memcpy, firstly loaded the data from SRC and buffered them in several
registers and combined as a new word( 16 bytes), then stored it to the aligned DST. But the performance is a
bit worst.

~Zhichang

>>> --
>>> 1.9.1
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2014-08-13  3:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-08 23:02 [PATCH V2] arm64: optimized copy_to_user and copy_from_user assembly code Feng Kan
2014-08-11  3:01 ` Radha Mohan
2014-08-11 18:05   ` Feng Kan
2014-08-13  3:13     ` zhichang.yuan [this message]
2014-08-13  8:19       ` Dr. Philipp Tomsich
2014-11-27 11:43 ` Steve Capper
2014-12-02 22:59   ` Dann Frazier
2014-12-03 20:01     ` Craig Magina
2014-12-04 12:27       ` Steve Capper
2014-12-04 13:56         ` Dr. Philipp Tomsich
2014-12-09 22:18           ` Dann Frazier
  -- strict thread matches above, loose matches on Subject: below --
2014-12-09  0:38 Feng Kan
2014-12-09  0:38 ` Feng Kan

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=53EAD7C8.7070001@linaro.org \
    --to=zhichang.yuan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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.