[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/mm: slightly relax TLB-flush-local check again


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 29 Apr 2022 15:38:08 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ASbVOOqJ46tYjj2FWN5KqziuUCuTnjB+Pfz6dFMuL9o=; b=dq2Lq5/wIshBndVTKideIdeSvkyRT3zIQRYiiUJg5SNAKdWpzMVthUHhoark3refqt3y6Me7VFWNv+IPb7SqCpcaoEqUGiXx/allwxVsBlTXnFJsjiLYS6R9somwnqC9dtDVDejM7DqFzF7psPau0DIY7YWuFcezP1QpIstz3LgJKSJoLKIwOJ8TKH+K69AMKaKoMsrvjIWcTKARkVXpIT87nvsjaYJvgdZdOqj4Za7WF0Cbp5rmGoRayjjFr0IuqTcVlmHoE5y0iofRNNRHh3KH9FY3vGHaY17MHqcyEMOUuC1AjTc1aHfNMsTeKOjJ5zYK1Qf+7qLs/GUrto5Srg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aw1dc7VUzKQxZjMAxGuA3clnUxdEDK6NILKtfxCFHVqHg82L9U7rRbPjtpLrVuqF3yrcLTV+ODjkQwHR51L1MgCBh3u/yLEirfsKhu8PBMpFD/W9kekEvgT/CcNjwnNZzKy36vS7YoN1JgSlrbYKqMhcEaiuzlP93ml8+LZkhtYzL1gc3dPbYcS1HjSbo+J0hV8uJ87MOg3iLOzHSe4GQcJgT8MnSB0GgB4jMiaKhuykAg2Px0bdyqfqCkynsbn8qUjPLJqIwrRR5GLseotbmyCpaKL7BrGs3WnG6JgUWtiSzImBQJRtob+FY+O2XVuyNb244zzMhkXy3yGL3DBZJA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, David Vrabel <dvrabel@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 29 Apr 2022 13:38:21 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 29.04.2022 15:32, Andrew Cooper wrote:
> On 29/04/2022 14:20, Jan Beulich wrote:
>> system_state changes to SYS_STATE_smp_boot before alternative_branches()
>> is invoked, yet that function, with CET-SS enabled, needs to invoke
>> modify_xen_mappings(). Convert to check for the number of online CPUs,
>> just like was done also in 88a037e2cfe1 / fa6dc0879ffd ("page_alloc:
>> assert IRQs are enabled in heap alloc/free", both instance of which
>> needed reverting for other reasons).
>>
>> Fixes: 78e072bc3750 ("x86/mm: avoid inadvertently degrading a TLB flush to 
>> local only")
>> Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> Only build-tested, as I don't have suitable hardware at hand.
> 
> I'll give it a test in just a moment, and while semantically I think
> it's probably right, I don't think we want to express the logic like this.
> 
> num_online_cpus() is cpumask_weight(&cpu_online_map) behind the scenes
> which is obnoxiously expensive for what we want.
> 
> For cases where we care just about UP vs SMP-ness, can't we just have an
> bool which is re-evaluated each time we take a CPU online/offline?  That
> should be far lower overhead.

Perhaps, but then I'd immediately ask: Why boolean? We could then as well
have a variable holding the count, such that num_online_cpus() wouldn't
need to invoke cpumask_weight() anymore at all.

In any event I view this as an orthogonal change. It's not entirely without
risk, as all updates to cpu_online_map would now also need to update the
variable. There shouldn't be too many right now; my main concern would be
with future additions.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.