Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp775702ybb; Sat, 28 Mar 2020 09:47:12 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuoQHWRBF29nKOfk7w/SQbzgCjRnsznRKvKbQdJvDRhWoCUoMJHkDGLpWRzTEeyszvhz/jF X-Received: by 2002:a4a:ba0b:: with SMTP id b11mr3975145oop.92.1585414031988; Sat, 28 Mar 2020 09:47:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585414031; cv=none; d=google.com; s=arc-20160816; b=m46x0hot/SXkVy5rCwaPpjlea4tCoplluzw1vy/oetdxFqnsRpCZaU7Hz+vtdD7FsP eQM7FORkDZh6ZwMYPd/hic/DN4bUTzVRrEWQHMXOnIVGhudAbYB0CBZ+/S8rSAVssNev hrGEv+95kMCYjG+9aBIc5xeldh/sljMP4bdVn7XI0M2ljfgDm8AUhlqhq3YIWtu7tbAN okm7HJJsYY595i5GwzI97pbTFbVeIDuEU9fo7bJ1Idw/tgjiodiJSU8OfuWm2y8KYX+Q FKGEV9i6WTE6PXlqvTmp+KYfEuxRWR9d1WGdlMMuvpummLES93YvMcCjl4anmhmqvMep JA/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:date:from:message-id; bh=fFPAnUU/Poyos/hHc+p3ftnWFUCpEuHNUeyDd5y0OZE=; b=OlROdMkuZH7XnlH0+UMDfpJpr7P3eYHqOuAu6NhSL+tlpz9TcvDh7wPsOqK2lPdHCg SD/lS8Xj+lqyxssugDV4KNP+D7vKHxl521DxomBeUm31Lc/jkYGbBU/qAXmV3lbSzuxj lGKEqPnt70cr9EezVK82poWLxh6JAlvNDrtjGqXIv0w0ElLc3XiGLhCeZX4Ob6YirK0u ZAGTLOOwZ7fi8WCqJHL3jUMNtVzcPlGZbPu7gDh85Fv3vTo454LosAT1D9S5vc3nrYmb yLuhW2IjDJ78ADEiNBKOh3mwAfaW4SIYreVwMYP8B1veYA3pEFRpYl8PO4tmeVatadEM 5dsQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a185si3730984oii.252.2020.03.28.09.46.58; Sat, 28 Mar 2020 09:47:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728167AbgC1QqM (ORCPT + 99 others); Sat, 28 Mar 2020 12:46:12 -0400 Received: from mx.sdf.org ([205.166.94.20]:50106 "EHLO mx.sdf.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727614AbgC1QnZ (ORCPT ); Sat, 28 Mar 2020 12:43:25 -0400 Received: from sdf.org (IDENT:lkml@sdf.lonestar.org [205.166.94.16]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 02SGhKv0008118 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 28 Mar 2020 16:43:20 GMT Received: (from lkml@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 02SGhKpM009093; Sat, 28 Mar 2020 16:43:20 GMT Message-Id: <202003281643.02SGhKpM009093@sdf.org> From: George Spelvin Date: Thu, 3 Oct 2019 04:55:27 -0400 Subject: [RFC PATCH v1 34/50] mm/slub.c: Use cheaper prandom source in shuffle_freelist To: linux-kernel@vger.kernel.org, lkml@sdf.org Cc: Thomas Garnier , Yu Zhao , Sean Rees Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The pre-generated permutation which we're choosing a random starting offset into was itself generated with prandom (in freelist_randomize()), so there's not much point using a crypto-quality generator here. Also, prandom_u32_max() uses a multiplicative algorithm for generating random integers in a range, which is faster than modulo. TODO: Figure out a better algorithm for the whole thing. A single permutation with a random starting point is a bit limiting. Can we make a full shuffle fast enough. or do we need to stick with something less general? We could easily add an outer offset: off2 + random_seq[off1 + i] Perhaps instead of just a random starting point, a random start and step? Unfortunately, the step must be relatively prime to the count, and the latter is not chosen to make things convenient. But it's easy enough to precompute a list of possible steps. Or we could at least allow steps of +1 and -1. Should random_seq be changed periodically? It's a separately allocated structure, so it's easy to allocate a new one and swap it out atomically. or even an Enigma-style double rotor: page[i] = off3 + random_seq2[off2 + random_seq1[off1 + i]] Signed-off-by: George Spelvin Cc: Thomas Garnier Cc: Yu Zhao Cc: Sean Rees --- mm/slub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slub.c b/mm/slub.c index 8eafccf759409..94d765666cff0 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -1580,7 +1580,7 @@ static bool shuffle_freelist(struct kmem_cache *s, struct page *page) return false; freelist_count = oo_objects(s->oo); - pos = get_random_int() % freelist_count; + pos = prandom_u32_max(freelist_count); page_limit = page->objects * s->size; start = fixup_red_left(s, page_address(page)); -- 2.26.0