From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55D7CC54EAA for ; Mon, 23 Jan 2023 08:17:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE5E76B0071; Mon, 23 Jan 2023 03:16:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A969A8E0001; Mon, 23 Jan 2023 03:16:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95D286B0073; Mon, 23 Jan 2023 03:16:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 86BAA6B0071 for ; Mon, 23 Jan 2023 03:16:59 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 5E8321A0709 for ; Mon, 23 Jan 2023 08:16:59 +0000 (UTC) X-FDA: 80385358158.01.78102F4 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) by imf06.hostedemail.com (Postfix) with ESMTP id 68088180015 for ; Mon, 23 Jan 2023 08:16:57 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="PbtbFjx/"; spf=pass (imf06.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.128.42 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674461817; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=mASwyI0y84zkiwwYs/n5l2nc6iOYa0RADtrERsvZZ/4=; b=5fIjMXhr70naviwmKddkgvJGHZ1BB81Fe5nSkacihrgIWlRZZfszu5L9xRp1LXqXONk+kB YaUbEcOV0NOrsnfS1DB5x/UEADxE5yfILXYNNBnV/wrys155MlWQm3fFqdcqDrc31Yoz+e EDHqJTNqEKFY8Tm4XmmFTmOQYHQ1Tek= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="PbtbFjx/"; spf=pass (imf06.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.128.42 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674461817; a=rsa-sha256; cv=none; b=RwuFLGyQkNdZ1lam7XZghoTJ7KZoNFQiqfOtN+wqnmPD9l1uGl30EUIBOTDdFwFpp4Wdo4 A033H0ITMx5CyrpdWUQPilxay7ZfSgHLkkNgZuC93Vmy6NpPTGtlJRqmE+ilLDG/Pg9UyS Z+am0flzUFr5RzOUxtGeapnnfH+lzdk= Received: by mail-wm1-f42.google.com with SMTP id q10-20020a1cf30a000000b003db0edfdb74so3881970wmq.1 for ; Mon, 23 Jan 2023 00:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mASwyI0y84zkiwwYs/n5l2nc6iOYa0RADtrERsvZZ/4=; b=PbtbFjx/YiFhnvdSh29MEa6PF9nytW6aCWO3mfmnb/mQIcXmYF78LAsc2CggFv8ULD e4BRWhtMDFcjb48YrV5CwLYYEDCSPpFwiZtDp3EIPeH4ghdvc/kRyAgMJZFsjxPBIoTz +SoqSV1LzOhYpwZP13Fz2w7f8NCsVFjpHxINOB7Fv4jVkf8oPTVcds0QmhBw/FdMKTv3 C3YWOZXlKHC0ry7oZ/l4Dn9zEN/mCuHKvr5terRV3WZlPSZGrqDpxLJDEVtSKWbICyJo TUdsnRByRwYR97rhmP9tjgC7v4IL/MFGCM/gxVMcS86Dkk73qsm7esM5DLU3bXjo/yG2 nBTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mASwyI0y84zkiwwYs/n5l2nc6iOYa0RADtrERsvZZ/4=; b=jcoaqBqgpTS8Lrz0TZyAgByodZnIxV4G330sonm3tbJjCi8JdzYwCK+4EEm9+Rgvcs KOyTjWNL9AufR4j5+xSqya+kN0yiwSsDiKvNHzajlYoy8HHQr/n2q4J1eN/eWQmFTF6L w8rpZVNqp7yXP+6EWRJhZFruj+2OzMJCmo0HGvubCfQE+dJgHHGtythY6QZfhduZO2kf P9cMxHn+Z18fx255rzYm3fqftjMx/2AWBBKmR/DPUJ4MDKdqCW9pZLn9wOInCp3aBnh5 UxXR0Uyfb7lEJFVCKnwg7veWhlMe7sg2f9xHxFWHdIlaP4pTvDLw7T28jVujoKQzpUeK vt/g== X-Gm-Message-State: AFqh2ko9Z8uSCmszqFvdcTEqCmEWndmCRkJE9XhUqFlEQfRapZp5cbq9 te5yMXo3IJV0130kLKQ8zns= X-Google-Smtp-Source: AMrXdXs78YIwmy6vXp8dUen1lH+gRIzlW9AG1nDQeN2sZijzpWuNRWZPH+x2GWIkurJEuK4QH4aP5A== X-Received: by 2002:a05:600c:1c8e:b0:3d9:e5f9:984c with SMTP id k14-20020a05600c1c8e00b003d9e5f9984cmr23361419wms.2.1674461815625; Mon, 23 Jan 2023 00:16:55 -0800 (PST) Received: from [192.168.86.94] ([77.137.66.37]) by smtp.gmail.com with ESMTPSA id p7-20020a05600c468700b003db0bb81b6asm10522350wmo.1.2023.01.23.00.16.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Jan 2023 00:16:55 -0800 (PST) Message-ID: Date: Mon, 23 Jan 2023 10:16:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.7.0 Subject: Re: [PATCH v6 3/5] lazy tlb: shoot lazies, non-refcounting lazy tlb mm reference handling scheme Content-Language: en-US To: Nicholas Piggin Cc: Andrew Morton , Andy Lutomirski , Linus Torvalds , linux-arch , linux-mm , linuxppc-dev@lists.ozlabs.org References: <20230118080011.2258375-1-npiggin@gmail.com> <20230118080011.2258375-4-npiggin@gmail.com> <5F3590B8-3F25-4EFB-BE3A-D32AAAC0B2F4@gmail.com> From: Nadav Amit In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: wx5zfgg8wycq3k4ezmfidfgcn3k39dfc X-Rspam-User: X-Rspamd-Queue-Id: 68088180015 X-Rspamd-Server: rspam06 X-HE-Tag: 1674461817-672472 X-HE-Meta: U2FsdGVkX18wHV/VL/td70FaoXJC2hBx07sJ1NZtseoY9uzrGECxvuh+wekYusm7L/ZxEa5P8O5Va74kuayq4AkUOi8ccQVMo+les5xLSeBU9k8NUjmQAJObGeFZajbZ/T0t1DRqpECr+F8aMSMAEUkCRCX7hPFgChtajfCPmdIt16dNYRVrdUKxxykMBoD4Pwz5KvOi1nol3a49QEk1+cOrnxdsdqJW3ufk32Am8gddRDHcaidBQyZhHE/9qCHh7k6ihclLONIhQcvRlTbJ2lKY6hsc+GxVaPzg0dliWd+2J7Pamig1Rh5pfI20xbKo8lsl8/Jc/up0s6xAJKL9Vg5SXImSsSewmV85rG6w1WeYeSWy7jB6ZRmV3fN42bdjZu4conAN+6XuPk+xoBDatTYjCJOoQZ3NGvjyUp6QLuUMlWd5fgCsg4YkJOB/ahASWCzCumBll7i8ryfXh7d37vDNC4vjUcbOgbwITtoen8qDfKo7W6IVZxlbpJftejMU+5xUyrU4mw5NYSx3X0RIyI1DvXBP6MuoGoNT540bz8hzaWZ55H+fkvrxtjrPTwKqc4QZqY635taL4qQcd9W6miagUuVoa2/ZLVK4haGtc9yYKt5keEd9xHXoUHI/WUb7hRjWSQ8OZCC26Mf3HDebBxonMMLABryqK8lIu99dvuW4hOhfXXXBMQZEpDKkNsUqGsvBByuAf7JiDIOdOIqrd36VR0+/N4j3sKpQYAoxhj4SLbzIJu0R4SruJqLi07jkPb4SaUF8k5YvdmNjzMkz+fdULYBu80gRl4F5pmqsvnSwFIOA43D5nkNJXW8ItsIwEHACDjunqW+q0urEAglP+c0gj4XfUoIkDHYaO4fdkgB70TTDt/+P7zFISfPgzFBw2lze8k2jFja1jRdNOBkpLRGWD5hsGlgns2WR/UvtGths32wldL7HsCOJuMksVQ4CDyB0jh8LplrDwZPEnYw O3ec6/mp /tuBDb6oBLMSzd2WpceTi35HCc18UPmhs4wYiymsxsiqiaGrIrmHFzhDkYaxdmstErSoAlAzcXzFXCV109rVtGjyPNj0vYlTeRiRqmQ7g08SLjCCfda0XrzSOJmthgPB9aVPAFayzFITjSeg/DxgeFxAvy2L5ntH1HwcWn/9cf1FqN38Eza7Q+jKC3h5kUKdfZ5iiVJrGcxYGHviFq02ZwCCjy5sIFJmuM3UCooEY2DY8ETYLrOArxq7ebaJBkbnRATWA1h6MTSnRr4Iwr7S+UP4XDVBhm4pF2r+gUrlyLEocch1Y1MaMOnSDKbkW7ItXMxNtSj7JRQY2LH5HF3lVrflHOJbk+nK9/ANSvxG7CzfdgWrzVnRjbRbetxltQ6wozLaKwO724z0J5EDftSXXo3kRuC8RaiSIGRC/bfJ6bDoPIic6b673BbAPiQVam6yf0BDlu4XArjcl4RzY+HtGWsQ29pxqfvQqk8N1MDP+RDqUdoHy7oOIBF3sv/j60bR2SyPknlH+RbBWzEQc8+GVHj1C9OpyKRYk1RSpU6eRSXw7Xcd/UculjnN8Aoiet2uDftJnKcHKjV3os4A+3yZtLz4DtYshbHT+GF9qcuBh4JROPqRWQvekjHkvCQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 1/19/23 6:22 AM, Nicholas Piggin wrote: > On Thu Jan 19, 2023 at 8:22 AM AEST, Nadav Amit wrote: >> >> >>> On Jan 18, 2023, at 12:00 AM, Nicholas Piggin wrote: >>> >>> +static void do_shoot_lazy_tlb(void *arg) >>> +{ >>> + struct mm_struct *mm = arg; >>> + >>> + if (current->active_mm == mm) { >>> + WARN_ON_ONCE(current->mm); >>> + current->active_mm = &init_mm; >>> + switch_mm(mm, &init_mm, current); >>> + } >>> +} >> >> I might be out of touch - doesn’t a flush already take place when we free >> the page-tables, at least on common cases on x86? >> >> IIUC exit_mmap() would free page-tables, and whenever page-tables are >> freed, on x86, we do shootdown regardless to whether the target CPU TLB state >> marks is_lazy. Then, flush_tlb_func() should call switch_mm_irqs_off() and >> everything should be fine, no? >> >> [ I understand you care about powerpc, just wondering on the effect on x86 ] > > Now I come to think of it, Rik had done this for x86 a while back. > > https://lore.kernel.org/all/20180728215357.3249-10-riel@surriel.com/ > > I didn't know about it when I wrote this, so I never dug into why it > didn't get merged. It might have missed the final __mmdrop races but > I'm not not sure, x86 lazy tlb mode is too complicated to know at a > glance. I would check with him though. My point was that naturally (i.e., as done today), when exit_mmap() is done, you release the page tables (not just the pages). On x86 it means that you also send shootdown IPI to all the *lazy* CPUs to perform a flush, so they would exit the lazy mode. [ this should be true for 99% of the cases, excluding cases where there were not page-tables, for instance ] So the patch of Rik, I think, does not help in the common cases, although it may perhaps make implicit actions more explicit in the code.