lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sat, 3 Aug 2013 20:50:33 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Airlie <airlied@...ux.ie>,
	Alex Deucher <alexander.deucher@....com>
Cc:	DRI mailing list <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm build fix

On Sat, Aug 3, 2013 at 6:08 PM, Dave Airlie <airlied@...ux.ie> wrote:
>
> Alex Deucher (1):
>       drm/radeon: fix 64 bit divide in SI spm code

That code is stupid. You're asking for a 64-by-64 divide, when the
divisor is clearly an "int" (100 and 1000 respectively).

Why is it doing "div64_s64()" instead of the simpler and faster "div_s64()"?

A full 64-by-64 divide is _expensive_ on 32-bit architecture (up to
four divide instructions, each potentially expensive in its own
right), which is the whole reason why we have that "math64.h" to begin
with - to make people aware of it.

Now, our lib/div64.c routines do notice that the upper bits of the
divisor are zero and end up using the simpler 64-by-32 divide
functions, but why explicitly ask for those more complex functions to
begin with?

So the code is likely not performance critical, and hey, our library
routines do the simple optimizations to avoid the trivially excessive
divide instructions, so this "doesn't matter". Except for the
annoyance factor of you using a more complicated function for no
reason.

                   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ