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 S1751231AbdKLNg2 (ORCPT <rfc822;w@1wt.eu>);
        Sun, 12 Nov 2017 08:36:28 -0500
Received: from Galois.linutronix.de ([146.0.238.70]:58917 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750779AbdKLNg0 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sun, 12 Nov 2017 08:36:26 -0500
Date: Sun, 12 Nov 2017 14:36:11 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Andi Kleen <ak@linux.intel.com>
cc: Prarit Bhargava <prarit@redhat.com>, linux-kernel@vger.kernel.org,
        Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
        x86@kernel.org, Peter Zijlstra <peterz@infradead.org>,
        Dave Hansen <dave.hansen@intel.com>, Piotr Luc <piotr.luc@intel.com>,
        Kan Liang <kan.liang@intel.com>, Borislav Petkov <bp@suse.de>,
        Stephane Eranian <eranian@google.com>,
        Arvind Yadav <arvind.yadav.cs@gmail.com>,
        Andy Lutomirski <luto@kernel.org>,
        Christian Borntraeger <borntraeger@de.ibm.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        He Chen <he.chen@linux.intel.com>,
        Mathias Krause <minipli@googlemail.com>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [PATCH v5 2/3] x86/topology: Avoid wasting 128k for package id
 array
In-Reply-To: <20171110150112.GI8522@tassilo.jf.intel.com>
Message-ID: <alpine.DEB.2.20.1711121423050.2288@nanos>
References: <20171105165428.32108-1-prarit@redhat.com> <20171105165428.32108-3-prarit@redhat.com> <alpine.DEB.2.20.1711071729270.1716@nanos> <372083ad-2a77-4646-bc67-dd4348a521d9@redhat.com> <20171110150112.GI8522@tassilo.jf.intel.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required,  ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 10 Nov 2017, Andi Kleen wrote:
> > > All of that works. There is no way to make sure that a lookup is fully
> > > serialized against a concurrent update. Even if the lookup holds
> > > cpu_read_lock() the new package might arrive right after the unlock.
> > > 
> > 
> > Thanks Thomas.
> > 
> > Andi, do you want to take a look at this?
> 
> I was originally worried about races, that is why i tried to put 
> everything into cpu_data. But that didn't work out because something
> clears it. Perhaps the right solution would be some extra per_cpu
> data variables, and search for the first match. I suspect that would
> be simpler. But if that doesn't work I guess something like Thomas'
> example will work.

Sure, we can use a separate per cpu variable. The race for looking up phys
-> logical will always be there if that handles stuff like the uncore PCI
physid one. There is not much which can prevent that.

The other option is to figure out what clears cpu_data on online and just
preserve the logical/physcial translation across that clear. 

One thing you need to be careful about (in both cases) is the value. The
data is zeroed on boot, so we either need to fill that with UINT_MAX at
boot time in one of the functions which does a for_each_possible_cpu() loop
anyway or just leave 0 as the 'not initialized' value and make the first
logical package be '1'. The readout functions (percpu, translation,
etc.) just can subtract 1.

Thanks,

	tglx