linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Joe Perches <joe@perches.com>,
	Scott Branden <sbranden@broadcom.com>,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	Jiandong Zheng <jdzheng@broadcom.com>,
	akpm@linux-foundation.org, David Woodhouse <dwmw2@infradead.org>,
	eric.dumazet@gmail.com
Subject: Re: [PATCH] mtd/nand: use string library
Date: Tue, 31 Jan 2012 09:57:26 -0800	[thread overview]
Message-ID: <CAN8TOE_e8FkTTABRTyrXr5EW3wsJeXaODE4Wpud4ype=tcRFFQ@mail.gmail.com> (raw)
In-Reply-To: <CAC5umyh6H-0JXyQ9V97FH_Cp7Y2swbRMJptXJwnE0cK6HqbkGQ@mail.gmail.com>

On Fri, Jan 27, 2012 at 3:52 PM, Akinobu Mita <akinobu.mita@gmail.com> wrote:
> 2012/1/28 Brian Norris <computersforpeace@gmail.com>:
>> On Fri, Jan 27, 2012 at 9:16 AM, Joe Perches <joe@perches.com> wrote:
>>> On Fri, 2012-01-27 at 23:24 +0900, Akinobu Mita wrote:
>>>> - Use memchr_inv to check if the data contains all 0xFF bytes.
>>>>   It is faster than looping for each byte.
>>>
>>> Stupid question:
>>>
>>> Are there any mtd devices modified that are slower
>>> at 64 bit accesses than repeated 8 bit accesses?
>>
>> I believe this patch deals with kernel buffers, not any kind of direct
>> access to the MTD, so the question (which is not stupid IMO) should be
>> regarding CPU architectures. And my educated guess is that 64-bit
>> access should not be any slower. I do know that 8-bit access *is*
>> slower for some relevant architectures.
>
> It could be slower when the number of bytes scanned is very small
> (found a unmatched character immediately, or the size of the area
> is very small), because memchr_inv() needs to generate a 64bit pattern
> to compare before starting the loop.  I recalled that Eric Dumazet
> pointed out it could generate the 64bit pattern more efficiently.
> (https://lkml.org/lkml/2011/8/8/480)
>
> Even if that small scanning is slower, this change can be assumed cleanup
> patch that simplifies the code.

Well, I agree that it qualifies as cleanup as well, but we should at
least make an attempt not to cause performance regression...

So by my understanding, the use of memchr_inv() is on buffers of
minimum length of 10 in this patch, so we're likely to have decent
results. And memcmp() usage looks fine to me.

So unless other concerns arise:

Acked-by: Brian Norris <computersforpeace@gmail.com>

  reply	other threads:[~2012-01-31 17:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-27 14:24 [PATCH] powerpc: use string library Akinobu Mita
2012-01-27 14:24 ` [PATCH] mtd/nand: " Akinobu Mita
2012-01-27 17:16   ` Joe Perches
2012-01-27 18:52     ` Brian Norris
2012-01-27 23:52       ` Akinobu Mita
2012-01-31 17:57         ` Brian Norris [this message]
2012-02-01 13:11           ` Akinobu Mita
2012-01-27 14:24 ` [PATCH] mtd/onenand: " Akinobu Mita
2012-01-27 14:24 ` [PATCH] mtd/ubi: use memchr_inv Akinobu Mita
2012-01-27 14:24 ` [PATCH] mtd/inftlmount: " Akinobu Mita
2012-01-27 14:24 ` [PATCH] mtd/nftlmount: " Akinobu Mita
2012-01-27 14:24 ` [PATCH] mtd/tests: " Akinobu Mita
2012-01-27 14:24 ` [PATCH] mISDN: " Akinobu Mita
2012-02-01 19:15   ` David Miller

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='CAN8TOE_e8FkTTABRTyrXr5EW3wsJeXaODE4Wpud4ype=tcRFFQ@mail.gmail.com' \
    --to=computersforpeace@gmail.com \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dwmw2@infradead.org \
    --cc=eric.dumazet@gmail.com \
    --cc=jdzheng@broadcom.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=sbranden@broadcom.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 NNTP newsgroup(s).