Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3170174imm; Sun, 29 Jul 2018 11:57:50 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfgKnXmWTbwU/q/Usx7YP42J+R/qEELBOfn7Y0R8eZQ/UeuCHl0XTozOWttDhjjJ5OOjQ1A X-Received: by 2002:a17:902:683:: with SMTP id 3-v6mr5550694plh.52.1532890670218; Sun, 29 Jul 2018 11:57:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532890670; cv=none; d=google.com; s=arc-20160816; b=uWKwWywYgRtFes80jYqpOd5vE67UMV/oFLF/THadWynaeeUfcTVRqBr+EshbxvGgHh 7UceZRvJ/3D8OTpF1+oIpLQQ2+qmtDmFzvh44XXj+TOfzPUB1OZ6mK7hiCE43fJ1wVlr iGELX3EjGrpef3RolISrui8h5ehzhs0iVLAnYLv9iaXGGqFA/1GIyMS8093+PIqkb0vn UdIprUrbj3f179YDLhYSQdhHoC/2wlBJ69NgYlwzCUDNqIbgczEbCKR73V40QbeIExg4 zlFgpOBXRCpKmWPALqHJNjhQasWPqXAxCEFFSbvQ8iUQBS2wi71yHCf2do1/YrS0IZd/ qI8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature:arc-authentication-results; bh=mxG8PF3ivFqhhpbhu4VGpFD6o3v5tUesaJ2RyZ87YpI=; b=zFm6iWYGX7SQ8JMHAzkO8MD4UHym094CUKXhP3oBglwWaA2FZ3zQaBIc6icr7iTPWd 9oW30iDTOtI9kibErm3ax0Snjig+K3YswCgDdT5WG11h0+uj9WFhfanAYiJZrzURp6Sr eC5ZCNZmAhN6fCO/PpY0YuMfq7LV338b2w7q6Idu6AvyZdn9cm3GnBDBP2SJw1KcEndX tqGJo6aSrljC7GfG4Zb+d3eZ0Il0qFoC1TioWt5d5qoM0GYQCeBmpKZNnOgfUxWKqJkJ JgQV9MBHnuZgecDMCMCAmkLGT5QXpmyBhYRBw1Kp8Ainl94PEWARW/k/FjIjtYnz0/Gx ezYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=pUo03la4; 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 193-v6si9265019pgh.407.2018.07.29.11.57.36; Sun, 29 Jul 2018 11:57:50 -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; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=pUo03la4; 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 S1730597AbeG2U06 (ORCPT + 99 others); Sun, 29 Jul 2018 16:26:58 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:34637 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726586AbeG2U05 (ORCPT ); Sun, 29 Jul 2018 16:26:57 -0400 Received: by mail-pf1-f194.google.com with SMTP id k19-v6so3538207pfi.1 for ; Sun, 29 Jul 2018 11:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mxG8PF3ivFqhhpbhu4VGpFD6o3v5tUesaJ2RyZ87YpI=; b=pUo03la42RFFoXo6t5zkrHhAt94CxtkJGJtxb0F8q8Rxgoc3HOrYS52ltPSpHmwgDE eWMnvgzzCfLVraUOllhYnO85STZx+SOVsZDyowfhZzeBgXcVcDbOb0NqXKU/WlF399NW OAf51+MmGZs4NDYY2NCjt2y4C0JxGysyy6dPsdCkp01a2IeWTOXRmvD0yEIIUbIo2nLs fX4KsmRAEzo3MtQIV7Aj+/ZcgXL3MQQfBYB7OTtEUqmVEbr03S5Wfa4MJiTiiy1XH0+q 5e5ZZbSutD8XUW+JAE89LkCSHcD2mHjciK3ARrk44al/Mb414U9/Sh6XRG6jd1LVQXEJ Jz6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mxG8PF3ivFqhhpbhu4VGpFD6o3v5tUesaJ2RyZ87YpI=; b=lzFSVBj923uRHPtrsbAHyoJFZrrxGbSrS0tvhIkKahZaioKQ247Y+R8uysQewZvLqQ MD7A5Uira/6AyqyYXdBolhaiIQ/J0e2+1pEkVI1Pl0D/7uBjiyjZ6JAsSGkj88NgmG1M MH6nTOUkdSxP73t3/LbJ4DOy+xdaGbhIh+0d7Xdtnndry8gqVurwZMzMy5JhLtRdxV8T RIVhENA2N6/fkfzMbldqS8oakLt6NRwlnMv3OsNJ1kuz19+AIFkqMFMGPMj13Gw5Hs4z qf/O5Vl3Rm4m2nYMv6daqGsfPNOfmftxYaMrnUT/RbHAbCWBDWf3wIkHhqESa3EO7a/n TNjg== X-Gm-Message-State: AOUpUlFy5eEQJH6e8IZtNHSEu2V/b7rnvKybChMFL3GbvqjtyDHEzDq0 iJJ3Pk1F/NSfppkiyWqCgAnBsw== X-Received: by 2002:a62:d8c:: with SMTP id 12-v6mr15007408pfn.202.1532890533290; Sun, 29 Jul 2018 11:55:33 -0700 (PDT) Received: from ?IPv6:2601:646:c200:7429:6c1c:6e0:41f7:badc? ([2601:646:c200:7429:6c1c:6e0:41f7:badc]) by smtp.gmail.com with ESMTPSA id l185-v6sm16808066pga.65.2018.07.29.11.55.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Jul 2018 11:55:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [PATCH 03/10] smp,cpumask: introduce on_each_cpu_cond_mask From: Andy Lutomirski X-Mailer: iPhone Mail (15G77) In-Reply-To: <1532886673.28585.24.camel@surriel.com> Date: Sun, 29 Jul 2018 11:55:30 -0700 Cc: Paolo Bonzini , Andy Lutomirski , LKML , kernel-team , Peter Zijlstra , X86 ML , Vitaly Kuznetsov , Ingo Molnar , Mike Galbraith , Dave Hansen , will.daecon@arm.com, Catalin Marinas , Benjamin Herrenschmidt Content-Transfer-Encoding: quoted-printable Message-Id: <8A3221EE-0D94-487E-B53D-885A555634BD@amacapital.net> References: <20180728215357.3249-1-riel@surriel.com> <20180728215357.3249-4-riel@surriel.com> <1532865634.28585.2.camel@surriel.com> <1532886673.28585.24.camel@surriel.com> To: Rik van Riel , torvalds@linux-foundation.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Jul 29, 2018, at 10:51 AM, Rik van Riel wrote: >=20 >> On Sun, 2018-07-29 at 08:36 -0700, Andy Lutomirski wrote: >>> On Jul 29, 2018, at 5:00 AM, Rik van Riel wrote: >>>=20 >>>> On Sat, 2018-07-28 at 19:57 -0700, Andy Lutomirski wrote: >>>> On Sat, Jul 28, 2018 at 2:53 PM, Rik van Riel >>>> wrote: >>>>> Introduce a variant of on_each_cpu_cond that iterates only over >>>>> the >>>>> CPUs in a cpumask, in order to avoid making callbacks for every >>>>> single >>>>> CPU in the system when we only need to test a subset. >>>> Nice. >>>> Although, if you want to be really fancy, you could optimize this >>>> (or >>>> add a variant) that does the callback on the local CPU in >>>> parallel >>>> with the remote ones. That would give a small boost to TLB >>>> flushes. >>>=20 >>> The test_func callbacks are not run remotely, but on >>> the local CPU, before deciding who to send callbacks >>> to. >>>=20 >>> The actual IPIs are sent in parallel, if the cpumask >>> allocation succeeds (it always should in many kernel >>> configurations, and almost always in the rest). >>>=20 >>=20 >> What I meant is that on_each_cpu_mask does: >>=20 >> smp_call_function_many(mask, func, info, wait); >> if (cpumask_test_cpu(cpu, mask)) { >> unsigned long flags; >> local_irq_save(flags); func(info); >> local_irq_restore(flags); >> } >>=20 >> So it IPIs all the remote CPUs in parallel, then waits, then does the >> local work. In principle, the local flush could be done after >> triggering the IPIs but before they all finish. >=20 > Grepping around the code, I found a few examples where the > calling code appears to expect that smp_call_function_many > also calls "func" on the local CPU. >=20 > For example, kvm_emulate_wbinvd_noskip has this: >=20 > if (kvm_x86_ops->has_wbinvd_exit()) { > int cpu =3D get_cpu(); >=20 > cpumask_set_cpu(cpu, vcpu->arch.wbinvd_dirty_mask); > smp_call_function_many(vcpu->arch.wbinvd_dirty_mask, > wbinvd_ipi, NULL, 1); > put_cpu(); > cpumask_clear(vcpu->arch.wbinvd_dirty_mask); > } else > wbinvd(); >=20 > This seems to result in systems with ->has_wbinvd_exit > only calling wbinvd_ipi on OTHER CPUs, and not on the > CPU where the guest exited with wbinvd? >=20 > This seems unintended. >=20 > I guess looking into on_each_cpu_mask might be a little > higher priority than waiting until the next Outreachy > season :) >=20 The right approach might be a tree wise rename from smp_call_... to on_other= _cpus_mask() it similar. The current naming and semantics are extremely conf= using. Linus, this is the kind of thing you seem to like taking outside the merge w= indow. What do you think about a straight-up search_and_replace to make rena= me the smp_call_... functions to exactly match the corresponding on_each_cpu= functions except with =E2=80=9Ceach=E2=80=9D replaced with =E2=80=9Cother=E2= =80=9D?=