Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3118308imm; Sun, 29 Jul 2018 10:40:18 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfNbm+ksnB6wypm+HYEay8lwQTo+Om9d3Ul+8rdPzkz+g78u3DECPR3UaTGtWrAeeAdxBvU X-Received: by 2002:a62:47c4:: with SMTP id p65-v6mr14970592pfi.170.1532886018723; Sun, 29 Jul 2018 10:40:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532886018; cv=none; d=google.com; s=arc-20160816; b=J2k7ilsWv5GPtMaOWSqE7nvAKmLHLTnyNHyC5pUPkOOspcJIKqL/izo7ad4jqVzlBf tUKpEPZEtE0T88rCUoHV9PBGFNlZCPcYhb/KlOgiBZXRguWuS+VS3QebflQly4pdsEBQ D1k4g1ChiFiOSPkqONbeEeyJNdP+i4G6jtKjqHIB664IMkk2HX0N+BMz3BRXZwlTVTDF S3L5O6GaQ2mxANE/q3xxGyS0EMYHcLy4hPr3q0707Ip51OeFKbN79MUMhLKEv6qKlwhQ g2FhZ32NrDNgDFy8xEzwxstT7ygwSTc3/xG9unHo4dvUqxVmpSFBdVbXWcw8qmN8FeES dFxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to:date :cc:to:from:subject:message-id:arc-authentication-results; bh=mv2qnfv0LX9IVLXxkrMzaHPGj2jrfzhbjYvi+rxI7g0=; b=a5z3Zp1ZwtaV4hU6RjIaSl/vRe9oPulm+RLBqm7RwMERbabO/NAoqVmD3eNYuKZSWk 0MJzjJtSCanmo/7q0+FaPOaQQsIbNEYpO3zE79NKx0/0nSic7N6HmjP8AZLBeOFJg+a0 3mR91A90NZyK8LgtM8zKs60Y0Dh9obCIk3rwbV+fh+08JjBw75Iub4MP3uEaunwog5lm Kt97IH1QOudq6uF04iYUToqQ6AIbDIqp/UPiF9aYwY9oyL55wRrtw81XkLwPgQ7ZKzYE zCdCQ0NjzHxLC5o9WX/VR5Go6V6axryKNAr/d4+NFeRM4bUNNeOQmC8l4be+c+d52QXL G+FA== 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 t190-v6si9278663pfb.216.2018.07.29.10.40.04; Sun, 29 Jul 2018 10:40:18 -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 S1726545AbeG2TK2 (ORCPT + 99 others); Sun, 29 Jul 2018 15:10:28 -0400 Received: from shelob.surriel.com ([96.67.55.147]:48052 "EHLO shelob.surriel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726438AbeG2TK2 (ORCPT ); Sun, 29 Jul 2018 15:10:28 -0400 Received: from imladris.surriel.com ([96.67.55.152]) by shelob.surriel.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fjpev-0000i2-Lr; Sun, 29 Jul 2018 13:39:09 -0400 Message-ID: <1532885949.28585.20.camel@surriel.com> Subject: Re: [PATCH 03/10] smp,cpumask: introduce on_each_cpu_cond_mask From: Rik van Riel To: Andy Lutomirski Cc: 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 Date: Sun, 29 Jul 2018 13:39:09 -0400 In-Reply-To: References: <20180728215357.3249-1-riel@surriel.com> <20180728215357.3249-4-riel@surriel.com> <1532865634.28585.2.camel@surriel.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-YJ6J6367Vg/8hmVEmuKY" X-Mailer: Evolution 3.26.6 (3.26.6-1.fc27) Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-YJ6J6367Vg/8hmVEmuKY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. Sure, moving the function call for the local CPU into smp_call_function_many might be a nice optimization. A quick grep suggests it touch stuff all over the tree, so it could be a nice Outreachy intern project :) --=20 All Rights Reversed. --=-YJ6J6367Vg/8hmVEmuKY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAltd+70ACgkQznnekoTE 3oM6xAf+LW3b7ytQ/AWHWbd/6imsPNnK7yJLQf6DN8SbORaONdPYkisg+8O0sHdM 5uyNh6LxZqHRGuL5pk4cVLeAVXvDxcjV0gb45yd3ieN1GyOyVGMyO3eV0huPhlGB J26NfMJ4+wCKRwn9ZVclq3g9iUgZeUxb12aYqPam/aUKZ0HbbaF+VXhOxigqx7Pf g/uM+Sp3M/4AZbmRwRfovsxiu7h0yY9C+BOf/SVLiR1wNkD6DhfWOWHCdqdfWYqT wOGtt5SeGKobWa6NW+A6QBGyG+Rk5r7UnaUlnyo4+Vgc5pjP9+xXT2CxDgXB+tM3 d24Fwim3Cm8oVGoT+rYpX7ne8M9iNg== =BNtc -----END PGP SIGNATURE----- --=-YJ6J6367Vg/8hmVEmuKY--