All of lore.kernel.org
 help / color / mirror / Atom feed
From: axboe@fb.com (Jens Axboe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] null_blk: use sector_div instead of do_div
Date: Mon, 30 Nov 2015 14:49:50 -0700	[thread overview]
Message-ID: <565CC47E.9020209@fb.com> (raw)
In-Reply-To: <4449032.oPBtpzlXyB@wuerfel>

On 11/27/2015 02:31 PM, Arnd Bergmann wrote:
> On Friday 27 November 2015 10:07:54 Linus Torvalds wrote:
>> On Fri, Nov 27, 2015 at 5:49 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> -       do_div(size, bs); /* convert size to pages */
>>> -       do_div(size, 256); /* concert size to pgs pr blk */
>>> +       sector_div(size, bs); /* convert size to pages */
>>> +       sector_div(size, 256); /* concert size to pgs pr blk */
>>
>> Ugh.
>>
>> Dividing by 256 should never be done with do_div() *or* sector-div.
>
> You are right, I missed what should have been an obvious simplification.
> FWIW, the division by 256 should now be optimized automatically when the
> new asm-generic do_div() implementation is used (which in turn caused
> the type mismatch warning that I'm trying to avoid). Of course that
> is no excuse for writing silly code like that, and it doesn't catch the
> cases where the argument is a power-of-two variable number.
>
> The first do_div() is also questionable: 'bs' is a global variable
> from a module parameter that defaults to 512 and is fixed to 4096
> when the device is used for lightnvm. I would guess that we run into
> bugs if this is ever set to a number that is not a power of two,
> smaller than 512, or larger than PAGE_SIZE.

We can use the shift, but honestly, it's just setup code. For hot paths, 
avoiding the div is definitely of higher priority. And for the sake of 
people copy/pasting or similar, making it a shift is probably a good idea.

-- 
Jens Axboe

WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@fb.com>
To: Arnd Bergmann <arnd@arndb.de>, <linux-arm-kernel@lists.infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Matias Bjorling <m@bjorling.me>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] null_blk: use sector_div instead of do_div
Date: Mon, 30 Nov 2015 14:49:50 -0700	[thread overview]
Message-ID: <565CC47E.9020209@fb.com> (raw)
In-Reply-To: <4449032.oPBtpzlXyB@wuerfel>

On 11/27/2015 02:31 PM, Arnd Bergmann wrote:
> On Friday 27 November 2015 10:07:54 Linus Torvalds wrote:
>> On Fri, Nov 27, 2015 at 5:49 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> -       do_div(size, bs); /* convert size to pages */
>>> -       do_div(size, 256); /* concert size to pgs pr blk */
>>> +       sector_div(size, bs); /* convert size to pages */
>>> +       sector_div(size, 256); /* concert size to pgs pr blk */
>>
>> Ugh.
>>
>> Dividing by 256 should never be done with do_div() *or* sector-div.
>
> You are right, I missed what should have been an obvious simplification.
> FWIW, the division by 256 should now be optimized automatically when the
> new asm-generic do_div() implementation is used (which in turn caused
> the type mismatch warning that I'm trying to avoid). Of course that
> is no excuse for writing silly code like that, and it doesn't catch the
> cases where the argument is a power-of-two variable number.
>
> The first do_div() is also questionable: 'bs' is a global variable
> from a module parameter that defaults to 512 and is fixed to 4096
> when the device is used for lightnvm. I would guess that we run into
> bugs if this is ever set to a number that is not a power of two,
> smaller than 512, or larger than PAGE_SIZE.

We can use the shift, but honestly, it's just setup code. For hot paths, 
avoiding the div is definitely of higher priority. And for the sake of 
people copy/pasting or similar, making it a shift is probably a good idea.

-- 
Jens Axboe


  parent reply	other threads:[~2015-11-30 21:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-27 13:49 [PATCH] null_blk: use sector_div instead of do_div Arnd Bergmann
2015-11-27 13:49 ` Arnd Bergmann
2015-11-27 18:07 ` Linus Torvalds
2015-11-27 18:07   ` Linus Torvalds
2015-11-27 21:31   ` Arnd Bergmann
2015-11-27 21:31     ` Arnd Bergmann
2015-11-28  8:05     ` Matias Bjørling
2015-11-28  8:05       ` Matias Bjørling
2015-12-18 16:13       ` Arnd Bergmann
2015-12-18 16:13         ` Arnd Bergmann
2016-01-13 21:46         ` Arnd Bergmann
2016-01-13 21:46           ` Arnd Bergmann
2015-11-30 21:49     ` Jens Axboe [this message]
2015-11-30 21:49       ` Jens Axboe

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=565CC47E.9020209@fb.com \
    --to=axboe@fb.com \
    --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.