Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2853845imm; Sun, 29 Jul 2018 05:03:57 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfCNowyA72jkEIU/8LxK4oiDZC3kXwDbpjFVBxnIE94/MxujAN93u93vW5OYDzNnGHDlbkB X-Received: by 2002:a65:658d:: with SMTP id u13-v6mr12769003pgv.20.1532865837761; Sun, 29 Jul 2018 05:03:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532865837; cv=none; d=google.com; s=arc-20160816; b=Y++xY0Q4TY9Q0IhTSvjkG+fG9ItDmynEuX5OZqpFvIZbuH09SGMqzbGQB0QqBdAeU4 B4pfNh/oM6jUp/VbW8/m3mztal0Zb0XuBQnh49idL0XvrVuIbXpPDjvWODy1mRZRgNsg PTTiTX3PHVW7w1kl4btPPZy6DkA/HmDoyvMAjS9GHDvfj/bVs7uELcnDeliAR7bEJVMg c0Wip6ou+H8OY+d6SO+NDpgixcPhpJzrFh9qX9fCKvu93zIgN4CJfSJ4LtRrmt6MJvcM ee59KDAklUErO+cUq2maCYc6IVIryyu+um+Quex9ZsB7ztz4QXtCbzzcubLjLJvT7jhX NVdQ== 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=KniTaDzRxsCppiLOha6xGi113Emf970+mBKx02Patvo=; b=Yx2tEoA58q1Hc4xh8yQtcWF+5jwsMu5gnDwItgOvl5Dn473zQYgdiwi4kUet36z4B8 tFQKYWKJ0p4PMvqX1QtshBClj10FwxEfvAdP4zQY1x43KadwJYIXwOBQzSLadbpCd5Wf aZZf9U4an3yF2DjYKuJ7Npei7u/tKz1zaAFssSn1ilptpEqe22yaKO58lxjBCjW5oBhA eDXNhUI9lzhFPcF1PbFLktOr70R0NcgmW4to2EhtWCQ2nQrG0rah7CmmSVLB96/41ynv wY1o+s1KWzd3QQYbWpRNot03ELPe+k6+NhJNkZ/0Mbp6PT55qv6H2XZpMH16nczceHf/ 5HcA== 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 z12-v6si7255707pgu.692.2018.07.29.05.03.43; Sun, 29 Jul 2018 05:03:57 -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 S1726473AbeG2NdL (ORCPT + 99 others); Sun, 29 Jul 2018 09:33:11 -0400 Received: from shelob.surriel.com ([96.67.55.147]:46942 "EHLO shelob.surriel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726242AbeG2NdL (ORCPT ); Sun, 29 Jul 2018 09:33:11 -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 1fjkPY-0004sE-AE; Sun, 29 Jul 2018 08:02:56 -0400 Message-ID: <1532865776.28585.4.camel@surriel.com> Subject: Re: [PATCH 04/10] x86,mm: use on_each_cpu_cond for TLB flushes From: Rik van Riel To: Andy Lutomirski Cc: 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 08:02:56 -0400 In-Reply-To: References: <20180728215357.3249-1-riel@surriel.com> <20180728215357.3249-5-riel@surriel.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-XEwfSrrrHge77OiIjk6k" 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 --=-XEwfSrrrHge77OiIjk6k Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2018-07-28 at 19:58 -0700, Andy Lutomirski wrote: > On Sat, Jul 28, 2018 at 2:53 PM, Rik van Riel > wrote: > > Instead of open coding bitmap magic, use on_each_cpu_cond > > to determine which CPUs to send TLB flush IPIs to. > >=20 > > This might be a little bit slower than examining the bitmaps, > > but it should be a lot easier to maintain in the long run. >=20 > Looks good. >=20 > i assume it's not easy to get the remove-tables case to do a single > on_each_cpu_cond() instead of two? Currently it's doing the lazy > ones and the non-lazy ones separately. Indeed. The TLB gather batch size means we need to send IPIs to the non-lazy CPUs whenever we have gathered so many pages that our tlb_gather data structure is full. This could result in many IPIs during a large munmap. The lazy CPUs get one IPI before page table freeing. --=20 All Rights Reversed. --=-XEwfSrrrHge77OiIjk6k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAltdrPAACgkQznnekoTE 3oOk0gf9EYPFeawFl4542FfuxfHknusccCZ+PtsSBKP8J+FbGotZ9DSoABWLT947 cuQ5VexITQJROybH50b2sQtFaQWOxStYthhJZKS2CIICksjx1hz9ijfFu4U7C/U8 EI7JHV7cRtDJUzkP5axcH6/ZEbIMRIvUhI+cHDOzgE13fXGE01wJJLJwvQ46askO TQJGejYBwHH5QYxZE6sJOatWd+5JyGQlhDhF67m1he3AUyw2cgD4gVmvzXEOjdp9 qqceDBa7OgmGZG15/JSKDD+HLErIuKtktjNxANFsCQ9m5aeIRXE7tt5GJvLSHbN2 /YdYMaojIxU1y/6FbLLdwLErHHjd+A== =gFXc -----END PGP SIGNATURE----- --=-XEwfSrrrHge77OiIjk6k--