From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754736AbbJUSNS (ORCPT ); Wed, 21 Oct 2015 14:13:18 -0400 Received: from ns.horizon.com ([71.41.210.147]:32319 "HELO ns.horizon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1750732AbbJUSNR (ORCPT ); Wed, 21 Oct 2015 14:13:17 -0400 Date: 21 Oct 2015 14:13:16 -0400 Message-ID: <20151021181316.25618.qmail@ns.horizon.com> From: "George Spelvin" To: hpa@linux.intel.com Subject: Re: Thought about credit_entropy_bits() math Cc: linux-kernel@vger.kernel.org, tytso@mit.edu In-Reply-To: <5626B01F.9050305@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (Resend because I can't spell "kernel.org".) H. Peter Anvin wrote: > The main advantage with this approximation is that it doesn't need a > multiplication instruction. Instead, it can be implemented with two > shifts and a subtract on hardware for which multiplication is slow. Er... I'm as addicted to micro-optimization as anyone, which is why I posted all those various approximations, but I'm taking about going from one to two, not zero to one. The current approximaion is used right in the middle of a non-constant multiply: unsigned int add = ((pool_size - entropy_count)*anfrac*3) >> s; (Does Linux even run on any hardware without a multiply instruction? There are tons of multiplies all over the scheduler. The worst cases I can think of just have slow bitwise multiplies: the nommu 68000 and SPARCv7's multiply step.)