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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 F3BB3C2BA83 for ; Fri, 14 Feb 2020 13:03:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B1441222C2 for ; Fri, 14 Feb 2020 13:03:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="BIpZqOim" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B1441222C2 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4104C6B061E; Fri, 14 Feb 2020 08:03:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C4976B061F; Fri, 14 Feb 2020 08:03:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AF8D6B0620; Fri, 14 Feb 2020 08:03:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0033.hostedemail.com [216.40.44.33]) by kanga.kvack.org (Postfix) with ESMTP id 0E1EB6B061E for ; Fri, 14 Feb 2020 08:03:52 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8CF75941E for ; Fri, 14 Feb 2020 13:03:51 +0000 (UTC) X-FDA: 76488749862.09.beef39_3eb188e84ae21 X-HE-Tag: beef39_3eb188e84ae21 X-Filterd-Recvd-Size: 4514 Received: from mail-yb1-f193.google.com (mail-yb1-f193.google.com [209.85.219.193]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Fri, 14 Feb 2020 13:03:50 +0000 (UTC) Received: by mail-yb1-f193.google.com with SMTP id l75so4707693ybf.6 for ; Fri, 14 Feb 2020 05:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=/A8R8UOkD4yDtK+GSiGCNT/BvFt5uvGEQou3YQP3IY4=; b=BIpZqOim532Zxa2LyOItzCL+6lI2O0/3rG84R9r1LXY5NxTG7NSDIL88OXh/+BTLo6 njjoshGKn8GYiaIRtA1XbZgT65WDm3R1cHIgGfGZnCIHqX1KRy8cx1iW+t+BV7c52pJG KAaepKwuhieTO+lMsFQceaJrVFQYyu1z9/CL6ydfcyu9Z0qb1RxBvD5Gu5eWB9W1T3Qe 0waFA0/IgzqBBPpT8oIPOhJHs5KjZDfIa4djS7/WkEASPoylLYjA3qx+bLM3pYl7F1Qn moTpy9ALwU27dsd3RXsuksfUTwX/EFPv53rBC1B6MOWndkYqccPgnfM2+8R1jwa3VdsA Zg3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=/A8R8UOkD4yDtK+GSiGCNT/BvFt5uvGEQou3YQP3IY4=; b=l3v7toiSjvzX5TMZNn9cAYIN65LIUSH4aZJYw4haiuLUc69R8nRe0+Fu2exnmdVNfZ NMkOdoWlsFKNvJDaS+9Yd1pqC4jvBEBAC/wpKzSCZJE4kI0x4XcAXcdGJMDtUeEJkjvX h8oGdhUNIpiylzjdbt6A8LOon2xLAOiUywLMMd2QNQzgDZ67cpMRQUOBB14BoRyVgl4f t3fH9TxTJo7cviBUr87NXSGPlEc6fVsN2jGCJez3zCcz36XolcfVUYF4eJKzWsKklO2S ZO00CO2P3LKsdWUtbsEyQmqTCXbjiFNUYZS3F6Fj9CkZx29bmFqKOxRBmAJM2RGqtX4H gvjQ== X-Gm-Message-State: APjAAAU5AG8iuSn4iaJAt29nvdxCt75doOJPXmBJVcVrAcr69Uao41gD p6ZgePQFjHvo0Wv1H8iA+rINAU240RoKwcExpLBY4g== X-Google-Smtp-Source: APXvYqy/JCTISQRSL+I33Iu64uOlvZ8YXlGFNyJBNx2KFSIYSrkC+EA7VKdIOCZ/JltME6FiZvsmhAmufoTkO9fVjzc= X-Received: by 2002:a25:9006:: with SMTP id s6mr2421937ybl.303.1581685429728; Fri, 14 Feb 2020 05:03:49 -0800 (PST) MIME-Version: 1.0 From: Michel Lespinasse Date: Fri, 14 Feb 2020 05:03:38 -0800 Message-ID: Subject: [LSF/MM/BPF TOPIC] Replacing mmap_sem with finer grained locks To: lsf-pc@lists.linux-foundation.org Cc: linux-mm , Davidlohr Bueso , Jerome Glisse , Laurent Dufour , "Liam R. Howlett" , Matthew Wilcox , Vlastimil Babka , David Rientjes , Hugh Dickins , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" 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: Hi, I would like to propose this topic for LSF/MM 2020. This is a continuation of discussions that were started at LSF/MM 2019 and have informally continued since between the copied folks and I. The fact that mmap_sem locks the entire MM is causing a lot of problems. The fundamental design hasn't changed in 20+ years, though a number of hacks have been added (such as releasing the mmap_sem during page faults) to work around the worst issues with it. In modern threaded workloads, we often see multiple threads running non-overlapping memory operations, which end up unnecessarily blocking on each other because mmap_sem only supports locking the entire MM rather than just the address range each thread is operating on. I have been working on a patch set to replace the mmap_sem rwsem with a range lock, which should resolve this issue. This is currently implemented through the page fault path and some very narrow cases of mmap(); I am working to broaden the scope of the mmap changes before sending this patch set publicly; I also know Davidlohr and Vlastimil have been working on similar approaches in the past. Another approach that is being explored is speculative page faults; I know Peter and Laurent have been working on this in the past and Matthew is giving this another look at the moment. I think this is a different angle to approach the problem from; I think this solution is not as generic (my understanding is that it only works for the page fault path), but more efficient for the cases that it handles. I really would like to get a new discussion about this, to discuss the concrete proposals that people have been working on and set a direction moving forward. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies.