From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: James Bottomley <jbottomley@odin.com>
Cc: "vkuznets\@redhat.com" <vkuznets@redhat.com>,
        "ulf.hansson\@linaro.org" <ulf.hansson@linaro.org>,
        "andriy.shevchenko\@linux.intel.com" 
	<andriy.shevchenko@linux.intel.com>,
        "keescook\@chromium.org" <keescook@chromium.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "akpm\@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [PATCH v3 1/4] lib/string_helpers: change blk_size to u32 for string_get_size() interface
Organization: D03
References: <1446136250-11507-1-git-send-email-vkuznets@redhat.com>
	<1446136250-11507-2-git-send-email-vkuznets@redhat.com>
	<1446157677.25009.2.camel@Odin.com>
	<87d1vwskfu.fsf@vitty.brq.redhat.com>
	<1446250866.25009.54.camel@Odin.com>
	<87y4egpf57.fsf@vitty.brq.redhat.com>
	<1446522039.2189.49.camel@Odin.com>
	<87egg7fcpn.fsf@vitty.brq.redhat.com>
	<1446570148.6440.11.camel@Odin.com>
Date: Tue, 03 Nov 2015 21:57:36 +0100
In-Reply-To: <1446570148.6440.11.camel@Odin.com> (James Bottomley's message of
	"Tue, 3 Nov 2015 17:02:29 +0000")
Message-ID: <87h9l2dcn3.fsf@rasmusvillemoes.dk>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1659
Lines: 51

On Tue, Nov 03 2015, James Bottomley <jbottomley@odin.com> wrote:

>
> It was a suggestion when I explained what the missing sources of
> precision were, I don't think it's really a suggestion when it comes
> with an exemplary patch.

ex·em·pla·ry
adjective

    1.
    serving as a desirable model; representing the best of its kind.

Said exemplary patch produces "1.10 KiB" for size=2047,
blk_size=1. (This is caused by the introduction of rounding, and is
probably fixable.)

James, I do understand the algorithm you're trying to use. What I don't
understand is why you insist on using the approach of reducing size and
blk_size all the way before multiplying them. It seems much simpler to
just reduce them till they're below U32_MAX (not keeping track of any
remainders at that point), multiply them, and then proceed as usual,
This avoids having to deal with weird cross-multiplication terms, gives
more accurate results (yes, I tested that) and avoids the extra 64/32
division you introduce by decrementing i.

Rasmus

To be precise, the body I suggest is

	while (blk_size > U32_MAX) {
		do_div(blk_size, divisor[units]);
		i++;
	}
	while (size > U32_MAX) {
		do_div(size, divisor[units]);
		i++;
	}
	size *= blk_size;
	while (size > divisor[units]) {
		remainder = do_div(size, divisor[units]);
		i++;
	}

whether the last one should be > or >= is debatable; I think 1024 KiB is
better than 1.00 MiB.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/