From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934011AbcAYUBP (ORCPT ); Mon, 25 Jan 2016 15:01:15 -0500 Received: from mail-yk0-f193.google.com ([209.85.160.193]:34405 "EHLO mail-yk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933261AbcAYUBL convert rfc822-to-8bit (ORCPT ); Mon, 25 Jan 2016 15:01:11 -0500 MIME-Version: 1.0 In-Reply-To: <1453751131.2363.54.camel@HansenPartnership.com> References: <1453560913-134672-1-git-send-email-andriy.shevchenko@linux.intel.com> <1453560913-134672-4-git-send-email-andriy.shevchenko@linux.intel.com> <1453567445.2470.24.camel@HansenPartnership.com> <94D0CD8314A33A4D9D801C0FE68B40295BF3B840@G9W0745.americas.hpqcorp.net> <1453748172.2363.36.camel@HansenPartnership.com> <1453751131.2363.54.camel@HansenPartnership.com> Date: Mon, 25 Jan 2016 22:01:11 +0200 Message-ID: Subject: Re: [PATCH v3 3/4] x86/efi: print size in binary units in efi_print_memmap From: Andy Shevchenko To: James Bottomley Cc: "Elliott, Robert (Persistent Memory)" , Andy Shevchenko , Matt Fleming , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , "linux-efi@vger.kernel.org" , Rasmus Villemoes , Andrew Morton , "linux-kernel @ vger . kernel . org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 25, 2016 at 9:45 PM, James Bottomley wrote: > On Mon, 2016-01-25 at 21:28 +0200, Andy Shevchenko wrote: >> On Mon, Jan 25, 2016 at 8:56 PM, James Bottomley >> wrote: >> > On Mon, 2016-01-25 at 18:02 +0000, Elliott, Robert (Persistent >> > Memory) >> > wrote: >> >> > Using ffs leads to precision runaway >> >> How exactly?! > > Off by one. A size of 0xffffffffffffffff prints 18446744073709551615 B > rather than 20 GiB. Because it's not a 20 GiB. It's exactly 20 GiB - 1 B. AFAIU, the intention was to show _exact_ size. >> It's good you are doing this better, but I still vote for __ffs64(), >> since it would be faster on binary units. > > Is speed of a start of day print a particular concern? If it's cheap to do, why not to do? >> Also, in one version I tried to convert couple of other users which >> are using only KM (in general whatever range it would be) units. Any >> ideas how to modify to support them? > > You mean units in odd increments of 6 digits (so K, M, T ...)? no. The > logarithmic reduction is done to the base of the unit increment (1000 > or 1024) so it doesn't really fit this case and it would be hard to > adjust because we don't have enough precision in the remainder. > However, unless there's a huge need to keep it, I'd just fit to the > closest 3 digit increment and then everything would work. KM case: K) if 1 MiB > value >= 0 — prints in KiB M) if ∞ > value >= 1 MiB — prints in MiB. -- With Best Regards, Andy Shevchenko