All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
	david-b@pacbell.net, Tony Lindgren <tony@atomide.com>,
	linux-mtd@lists.infradead.org, vimal singh <vimalsingh@ti.com>
Subject: Re: [PATCH 2:2][MTD][NAND]omap : Adding DMA mode support in nand prefetch/post-write
Date: Fri, 10 Jul 2009 15:44:26 +0300	[thread overview]
Message-ID: <4A5737AA.7050208@gmail.com> (raw)
In-Reply-To: <1247229621.29541.4.camel@macbook.infradead.org>

David Woodhouse wrote:
> On Fri, 2009-07-10 at 15:02 +0300, Artem Bityutskiy wrote:
>> On Fri, 2009-07-10 at 17:25 +0530, vimal singh wrote:
>>> +	/* The fifo depth is 64 bytes. We have a sync at each frame and frame
>>> +	 * length is 64 bytes.
>>> +	 */
>>> +	int buf_len = len/64;
>> To optimize performance it is better not to rely on gcc and use <<
> 
> If you ever see gcc screwing up division of an 'int' by a constant 64,
> file a GCC bug.

I did see gcc generated division instruction instead of shift
instruction on x86 when the kernel is compiles with size optimization.
I think this is because it division instruction is shorter.

The exact place I we saw was the UBIFS binary search function, and
division by 2 was not compiled into a shift instruction.

So what I suggested is to use shift explicitly if this is wanted.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind1@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
	david-b@pacbell.net, Tony Lindgren <tony@atomide.com>,
	linux-mtd@lists.infradead.org, vimal singh <vimalsingh@ti.com>
Subject: Re: [PATCH 2:2][MTD][NAND]omap : Adding DMA mode support in nand prefetch/post-write
Date: Fri, 10 Jul 2009 15:44:26 +0300	[thread overview]
Message-ID: <4A5737AA.7050208@gmail.com> (raw)
In-Reply-To: <1247229621.29541.4.camel@macbook.infradead.org>

David Woodhouse wrote:
> On Fri, 2009-07-10 at 15:02 +0300, Artem Bityutskiy wrote:
>> On Fri, 2009-07-10 at 17:25 +0530, vimal singh wrote:
>>> +	/* The fifo depth is 64 bytes. We have a sync at each frame and frame
>>> +	 * length is 64 bytes.
>>> +	 */
>>> +	int buf_len = len/64;
>> To optimize performance it is better not to rely on gcc and use <<
> 
> If you ever see gcc screwing up division of an 'int' by a constant 64,
> file a GCC bug.

I did see gcc generated division instruction instead of shift
instruction on x86 when the kernel is compiles with size optimization.
I think this is because it division instruction is shorter.

The exact place I we saw was the UBIFS binary search function, and
division by 2 was not compiled into a shift instruction.

So what I suggested is to use shift explicitly if this is wanted.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind1@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: dedekind@infradead.org, vimal singh <vimalsingh@ti.com>,
	linux-mtd@lists.infradead.org, Tony Lindgren <tony@atomide.com>,
	david-b@pacbell.net, linux-kernel@vger.kernel.org,
	linux-omap@vger.kernel.org
Subject: Re: [PATCH 2:2][MTD][NAND]omap : Adding DMA mode support in nand prefetch/post-write
Date: Fri, 10 Jul 2009 15:44:26 +0300	[thread overview]
Message-ID: <4A5737AA.7050208@gmail.com> (raw)
In-Reply-To: <1247229621.29541.4.camel@macbook.infradead.org>

David Woodhouse wrote:
> On Fri, 2009-07-10 at 15:02 +0300, Artem Bityutskiy wrote:
>> On Fri, 2009-07-10 at 17:25 +0530, vimal singh wrote:
>>> +	/* The fifo depth is 64 bytes. We have a sync at each frame and frame
>>> +	 * length is 64 bytes.
>>> +	 */
>>> +	int buf_len = len/64;
>> To optimize performance it is better not to rely on gcc and use <<
> 
> If you ever see gcc screwing up division of an 'int' by a constant 64,
> file a GCC bug.

I did see gcc generated division instruction instead of shift
instruction on x86 when the kernel is compiles with size optimization.
I think this is because it division instruction is shorter.

The exact place I we saw was the UBIFS binary search function, and
division by 2 was not compiled into a shift instruction.

So what I suggested is to use shift explicitly if this is wanted.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

  reply	other threads:[~2009-07-10 12:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-10 11:55 [PATCH 2:2][MTD][NAND]omap : Adding DMA mode support in nand prefetch/post-write vimal singh
2009-07-10 11:55 ` vimal singh
2009-07-10 11:55 ` vimal singh
2009-07-10 12:02 ` Artem Bityutskiy
2009-07-10 12:02   ` Artem Bityutskiy
2009-07-10 12:02   ` Artem Bityutskiy
2009-07-10 12:40   ` David Woodhouse
2009-07-10 12:40     ` David Woodhouse
2009-07-10 12:40     ` David Woodhouse
2009-07-10 12:44     ` Artem Bityutskiy [this message]
2009-07-10 12:44       ` Artem Bityutskiy
2009-07-10 12:44       ` Artem Bityutskiy

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=4A5737AA.7050208@gmail.com \
    --to=dedekind1@gmail.com \
    --cc=david-b@pacbell.net \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.com \
    --cc=vimalsingh@ti.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 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.