From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753328AbbJWMb7 (ORCPT ); Fri, 23 Oct 2015 08:31:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35350 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751478AbbJWMb5 (ORCPT ); Fri, 23 Oct 2015 08:31:57 -0400 From: Vitaly Kuznetsov To: Rasmus Villemoes Cc: Andrew Morton , Andy Shevchenko , James Bottomley , linux-kernel@vger.kernel.org, "K. Y. Srinivasan" Subject: Re: [PATCH v5 2/2] lib/test-string_helpers.c: add string_get_size() tests References: <1442483044-9401-1-git-send-email-vkuznets@redhat.com> <1442483044-9401-3-git-send-email-vkuznets@redhat.com> <87eggor0bi.fsf@rasmusvillemoes.dk> Date: Fri, 23 Oct 2015 14:31:53 +0200 In-Reply-To: <87eggor0bi.fsf@rasmusvillemoes.dk> (Rasmus Villemoes's message of "Wed, 21 Oct 2015 12:19:13 +0200") Message-ID: <87egglhikm.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Rasmus Villemoes writes: > On Thu, Sep 17 2015, Vitaly Kuznetsov wrote: > >> + >> +static __init void test_string_get_size(void) >> +{ >> + test_string_get_size_one(16384, 512, STRING_UNITS_2, "8.00 MiB"); >> + test_string_get_size_one(8192, 4096, STRING_UNITS_10, "32.7 MB"); > > This is a little late, Thanks for the ping, it turns out this patch was never merged (though the one fixing the issue was), I'll have to resend. > but I just noticed that string_get_size with > STRING_UNITS_10, block size >= 1024 and sufficiently large size seems to > be broken. Yes, 32.7 MB is what it produces, but is it what it should > give? 8192*4096 = 33554432, so I'd expect "33.5 MB". It does give that > when we pass size=65536 and block_size=512; a combination with the same > product. > > I think the problem is that the remainder coming out of the while > (blk_size >= divisor[units]) loop is dropped on the floor in the > subsequent size > exp case - but I'm too lazy right now to figure out how > to fix it. Ok, I'll take a look. -- Vitaly