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 X-Spam-Level: X-Spam-Status: No, score=-17.0 required=3.0 tests=BAYES_00,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CF772C4361A for ; Fri, 4 Dec 2020 05:26:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2BD7A22581 for ; Fri, 4 Dec 2020 05:26:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2BD7A22581 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1E7406B0036; Fri, 4 Dec 2020 00:26:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1963A6B005C; Fri, 4 Dec 2020 00:26:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0681F6B0068; Fri, 4 Dec 2020 00:26:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0212.hostedemail.com [216.40.44.212]) by kanga.kvack.org (Postfix) with ESMTP id E005F6B0036 for ; Fri, 4 Dec 2020 00:26:24 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A760E180AD80F for ; Fri, 4 Dec 2020 05:26:24 +0000 (UTC) X-FDA: 77554464288.23.drum19_5f03131273c1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id 886AD37604 for ; Fri, 4 Dec 2020 05:26:24 +0000 (UTC) X-HE-Tag: drum19_5f03131273c1 X-Filterd-Recvd-Size: 2962 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Fri, 4 Dec 2020 05:26:23 +0000 (UTC) From: Andy Lutomirski Authentication-Results:mail.kernel.org; dkim=permerror (bad message/signature format) To: Nicholas Piggin Cc: Anton Blanchard , Arnd Bergmann , linux-arch , LKML , Linux-MM , linuxppc-dev , Mathieu Desnoyers , X86 ML , Will Deacon , Catalin Marinas , Rik van Riel , Dave Hansen , Nadav Amit , Jann Horn , Andy Lutomirski Subject: [RFC v2 0/2] lazy mm refcounting Date: Thu, 3 Dec 2020 21:26:15 -0800 Message-Id: X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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: This is part of a larger series here, but the beginning bit is irrelevant to the current discussion: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=3D= x86/mm&id=3D203d39d11562575fd8bd6a094d97a3a332d8b265 This is IMO a lot better than v1. It's now almost entirely in generic code. (It looks like it's 100% generic, but that's a lie -- the generic code currently that all possible lazy mm refs are in mm_cpumask(), and that's not true on all arches. So, if we take my approach, we'll need to have a little arch hook to control this.) Here's how I think it fits with various arches: x86: On bare metal (i.e. paravirt flush unavailable), the loop won't do much. The existing TLB shootdown when user tables are freed will empty mm_cpumask of everything but the calling CPU. So x86 ends up pretty close to as good as we can get short of reworking mm_cpumask() its= elf. arm64: It needs the fixup above for correctness, but I think performance should be pretty good. Compared to current kernels, we lose an mmgrab() and mmdrop() on each lazy transition, and we add a reasonably fast loop over all cpus on process exit. Someone (probably me) needs to make sure we don't need some extra barriers. power: Similar to x86. s390x: Should be essentially the same as arm64. Other arches: I don't know. Further research is required. What do you all think? Andy Lutomirski (2): [NEEDS HELP] x86/mm: Handle unlazying membarrier core sync in the arch code [MOCKUP] sched/mm: Lightweight lazy mm refcounting arch/x86/mm/tlb.c | 17 +++++- kernel/fork.c | 4 ++ kernel/sched/core.c | 134 +++++++++++++++++++++++++++++++++++++------ kernel/sched/sched.h | 11 +++- 4 files changed, 145 insertions(+), 21 deletions(-) --=20 2.28.0