From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 20 Feb 2020 21:51:46 -0000 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120] helo=us-smtp-1.mimecast.com) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1j4tjV-0008Sh-FL for speck@linutronix.de; Thu, 20 Feb 2020 22:51:45 +0100 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4127E801E5C for ; Thu, 20 Feb 2020 21:51:36 +0000 (UTC) Received: from treble (ovpn-123-230.rdu2.redhat.com [10.10.123.230]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E381187B11 for ; Thu, 20 Feb 2020 21:51:35 +0000 (UTC) Date: Thu, 20 Feb 2020 15:51:32 -0600 From: Josh Poimboeuf Subject: [MODERATED] Re: [PATCH 0/2] more sampling fun 0 Message-ID: <20200220215132.vl6mrauahldbzkfm@treble> References: <20200220081420.GA3328448@kroah.com> <20200220145510.GE160988@tassilo.jf.intel.com> MIME-Version: 1.0 In-Reply-To: <20200220145510.GE160988@tassilo.jf.intel.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Thu, Feb 20, 2020 at 06:55:10AM -0800, speck for Andi Kleen wrote: > > Then we need to stop using RDRAND internally for our "give me a random > > number api" which has spread to more and more parts of the kernel. > > Only if that API is called frequently enough. AFAIK it is not. > > Normally it's used for rare rekeying of hash tables etc., which > doesn't happen very often. > > > Here's a patch that does so: > > https://lore.kernel.org/lkml/20200216161836.1976-1-Jason@zx2c4.com/ > > which I'm going to advise get merged now and backported to the stable > > branches. > > Don't see any reason at this point. Only do it if there's an actual > indication of a problem. Internal testing of the SRBDS beta microcode on Kaby Lake is showing significant slowdowns in several syscall microbenchmarks. One pthread_create() microbenchmark had a ~48% slowdown. We confirmed it was due to RDRAND in get_random_u64(). In this case I think the path was: clone() _do_fork() copy_process() dup_task_struct() get_random_canary() (due to CONFIG_STACKPROTECTOR) get_random_long() get_random_u64() arch_get_random_long() RDRAND -- Josh