Received: by 10.223.176.46 with SMTP id f43csp4449859wra; Tue, 23 Jan 2018 09:33:16 -0800 (PST) X-Google-Smtp-Source: AH8x225dp8cJ/sMgbECOatAq6MYUzu5HK5RBGJa7KeZewAoHoCA4MhmWfoMsPtFRWFIZCfyPH75I X-Received: by 10.107.195.1 with SMTP id t1mr4622912iof.142.1516728796269; Tue, 23 Jan 2018 09:33:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516728796; cv=none; d=google.com; s=arc-20160816; b=Nyqa4wbh6l4UUaAHVWfnRkJPpGX0cYwAHrrRSWq865HiRt3DFNCbfe5zVSV/5idQCg ys8gWT2YSpIGcX7fwJD8FC7tX+Gx5G7BJIAiLy9JfFpzcmtXbb7L9AMpDbALUpkqCNj9 Wv+d3YnylqbmNvKs50K14tGf65sxrVvKDE6O46cAHujB+Y7GGHg79LWVfU3cRCTtdS4K aRwCOuOowomaGul7n4QZOPqmBXgP2D5JYVZumhckohhDaoRKWbqI7R1FMXYXxP8VYYna 4cDAPC0WydGIG0NaoIumzFK7Gnw12Q8moSHlRTLo8zdWDclNa1yvJSMgMB9bTV9TwWj8 eucA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=zeF6+qz7xqHkdPNGBhzBFBrMJJDwwrX0ZxWLb3AhfRk=; b=rc6gba695SNXcRVT7QB8JmDbpMdBls5OUzkQe3o0Dg+U7BSvpMwH9jOYqiUUCFmZyl zaDrodI8c3ZtjFRl9ccfHhMiirfb4zWG5i0xZsUwsCoYeCWpmHwf7QelfH3qCcvddrm7 Da+P/KdWrR9eGcyBymlyF2s7rYVPv+L6uKhoXHvNHjBpO05Qg/BKBY8tcg3iopvDZnfO AZV4FBpj2k7bkIbKhuTxiopxl4szbKZ6HXQLSc2TAC1mjqA8oE+XZe4xpifo3yaIp1Fg 3VE7/vuzIEDpEV1+JywP1RKa9Xs4gULEtcQ4RmYfNttTInTLppDWJbx3oYTHWCpXw3YQ tENg== 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 w129si8878787itd.71.2018.01.23.09.33.03; Tue, 23 Jan 2018 09:33:16 -0800 (PST) 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 S1751961AbeAWRc0 (ORCPT + 99 others); Tue, 23 Jan 2018 12:32:26 -0500 Received: from mail.skyhub.de ([5.9.137.197]:40616 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751347AbeAWRcY (ORCPT ); Tue, 23 Jan 2018 12:32:24 -0500 X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (blast.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pe3syiGtaPV6; Tue, 23 Jan 2018 18:32:23 +0100 (CET) Received: from pd.tnic (p200300EC2BD1D800B5F6B1F16569F43D.dip0.t-ipconnect.de [IPv6:2003:ec:2bd1:d800:b5f6:b1f1:6569:f43d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 671D91EC0577; Tue, 23 Jan 2018 18:32:23 +0100 (CET) Date: Tue, 23 Jan 2018 18:32:16 +0100 From: Borislav Petkov To: David Woodhouse Cc: x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/cpuid: Fewer CPUID invocations in init_scattered_cpuid_features() Message-ID: <20180123173216.x54vstw57hgkwxfm@pd.tnic> References: <1516719213-7199-1-git-send-email-dwmw@amazon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1516719213-7199-1-git-send-email-dwmw@amazon.co.uk> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 23, 2018 at 02:53:33PM +0000, David Woodhouse wrote: > We were doing a fresh CPUID for every single bit in every single output > register. Do it once and then harvest *all* the bits we want. > > We were also doing the max_level check with a new CPUID invocation for > every single bit. Stop that too. > > Signed-off-by: David Woodhouse > --- > Spotted this in my travels; it offended me. Ok, I see that it's itching so let's scratch it properly :-) If we're going to optimize scattered.c, let's do something like this: * do CPUID for each function once. * for each set bit in there, set feature flag which means we'd have to change the data structure. struct cpuid_leaf { u32 level; u32 sub_leaf; struct cpuid_bit bits[]; }; and that last thing is: struct cpuid_bit { u16 feature; u8 reg; u8 bit; }; So that you have something like (for example with leaf 0x10): struct cpuid_leaf leafs[] = { ... { .level = 0x00000010, .sub_leaf = 0, .bits = { { X86_FEATURE_CAT_L3, CPUID_EBX, 1 }, { X86_FEATURE_CAT_L2, CPUID_EBX, 2 }, { X86_FEATURE_MBA , CPUID_EBX, 3 }, { 0 } } } ... } This way you get the CPUID only once and then iterate over bits[] and you can do the cleaner max level computation cpuid_eax(level & 0xffff0000); without having to do the extended level checks. Anyway, something like that. It's probably not even worth doing anything though - I doubt the speedup is visible at all. But I certainly understand the intent to fix an annoying thing like that. :-)) Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.