From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263161AbTJPU27 (ORCPT ); Thu, 16 Oct 2003 16:28:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263166AbTJPU27 (ORCPT ); Thu, 16 Oct 2003 16:28:59 -0400 Received: from h68-147-142-75.cg.shawcable.net ([68.147.142.75]:21495 "EHLO schatzie.adilger.int") by vger.kernel.org with ESMTP id S263161AbTJPU24 (ORCPT ); Thu, 16 Oct 2003 16:28:56 -0400 Date: Thu, 16 Oct 2003 14:27:06 -0600 From: Andreas Dilger To: Matt Mackall Cc: Jeff Garzik , Eli Billauer , linux-kernel@vger.kernel.org, Nick Piggin Subject: Re: [RFC] frandom - fast random generator module Message-ID: <20031016142706.G7000@schatzie.adilger.int> Mail-Followup-To: Matt Mackall , Jeff Garzik , Eli Billauer , linux-kernel@vger.kernel.org, Nick Piggin References: <3F8E552B.3010507@users.sf.net> <3F8E58A9.20005@cyberone.com.au> <3F8E70E0.7070000@users.sf.net> <3F8E8101.70009@pobox.com> <20031016102020.A7000@schatzie.adilger.int> <20031016174526.GM5725@waste.org> <20031016123828.F7000@schatzie.adilger.int> <20031016190825.GQ5725@waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031016190825.GQ5725@waste.org>; from mpm@selenic.com on Thu, Oct 16, 2003 at 02:08:25PM -0500 X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Oct 16, 2003 14:08 -0500, Matt Mackall wrote: > On Thu, Oct 16, 2003 at 12:38:28PM -0600, Andreas Dilger wrote: > > It was a 2-way SMP system. We use the RNG a fair amount (enough to know > > that 2 CPUs can race and return the same value from get_random_bytes() ;-) > > Sure this is a race and not a birthday paradox? How recent is this? > Possibly before locking was added to random.c? This is with a 2.4 kernel, which AFAIK doesn't have any locking. > > so we had to put a spinlock around our calls to that. Even so, oprofile > > showed extract_entropy() and SHATransform() near the top of CPU users. > > Ok, the lock contention would be with add_entropy_words. I've got code > that reduces calls to SHATransform for /dev/urandom, but it require > addressing the starvation issues between /dev/random and /dev/urandom first. But there isn't an in-kernel interface to "/dev/urandom" so that doesn't help us. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/