From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1162363AbcE3U7s (ORCPT <rfc822;w@1wt.eu>);
	Mon, 30 May 2016 16:59:48 -0400
Received: from imap.thunk.org ([74.207.234.97]:48506 "EHLO imap.thunk.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1161690AbcE3U7n (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 30 May 2016 16:59:43 -0400
Date: Mon, 30 May 2016 16:59:31 -0400
From: "Theodore Ts'o" <tytso@mit.edu>
To: Andi Kleen <andi@firstfloor.org>
Cc: Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
        smueller@chronox.de, herbert@gondor.apana.org.au,
        sandyinchina@gmail.com, cryptography@lakedaemon.net, jsd@av8n.com,
        hpa@zytor.com, linux-crypto@vger.kernel.org
Subject: Re: [PATCH-v3 0/5] random: replace urandom pool with a CRNG
Message-ID: <20160530205931.GI12629@thunk.org>
Mail-Followup-To: Theodore Ts'o <tytso@mit.edu>,
	Andi Kleen <andi@firstfloor.org>,
	Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
	smueller@chronox.de, herbert@gondor.apana.org.au,
	sandyinchina@gmail.com, cryptography@lakedaemon.net, jsd@av8n.com,
	hpa@zytor.com, linux-crypto@vger.kernel.org
References: <1464586765-14436-1-git-send-email-tytso@mit.edu>
 <20160530175322.GB13997@two.firstfloor.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160530175322.GB13997@two.firstfloor.org>
User-Agent: Mutt/1.6.0 (2016-04-01)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, May 30, 2016 at 10:53:22AM -0700, Andi Kleen wrote:
> 
> It should work the same on larger systems, the solution scales
> naturally to lots of sockets. It's not clear it'll help enough on systems
> with a lot more cores per socket, like a Xeon Phi. But for now it should
> be good enough.

One change which I'm currently making is to use kmalloc_node() instead
of kmalloc() for the per-NUMA node, and I suspect *that* is going
to make a quite a lot of different on those systems where the ratio of
remote to local memory access times is larger (as I assume it probably
would be on really big systems).

						- Ted