linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Akinobu Mita <akinobu.mita@gmail.com>
To: Brian Norris <computersforpeace@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: Wed, 1 Feb 2012 22:11:11 +0900	[thread overview]
Message-ID: <CAC5umygV_Nmn_hE04qV1=xVcSWZJfVXMVJO-Y1sadJU4kYz94A@mail.gmail.com> (raw)
In-Reply-To: <CAN8TOE_e8FkTTABRTyrXr5EW3wsJeXaODE4Wpud4ype=tcRFFQ@mail.gmail.com>

2012/2/1 Brian Norris <computersforpeace@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.

Sorry, I answered without checking memchr_inv() carefully.  If the size
of buffer is less than 16 bytes, memchr_inv() scans for each byte as the
original code did.  So it is unlikely to be slower in the most cases.

But I mentioned in the previous email, there are some problems in
memchr_inv().  I'll send the patch in a few days.

> So unless other concerns arise:
>
> Acked-by: Brian Norris <computersforpeace@gmail.com>

Thanks.

  reply	other threads:[~2012-02-01 13:11 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
2012-02-01 13:11           ` Akinobu Mita [this message]
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='CAC5umygV_Nmn_hE04qV1=xVcSWZJfVXMVJO-Y1sadJU4kYz94A@mail.gmail.com' \
    --to=akinobu.mita@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=computersforpeace@gmail.com \
    --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).