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=-13.1 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1, 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 414ADC433DF for ; Sat, 15 Aug 2020 00:26:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D77732074D for ; Sat, 15 Aug 2020 00:26:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="tixNdcgK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D77732074D 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 3F10F6B0002; Fri, 14 Aug 2020 20:26:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A0276B0005; Fri, 14 Aug 2020 20:26:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B8C56B0006; Fri, 14 Aug 2020 20:26:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) by kanga.kvack.org (Postfix) with ESMTP id 159CD6B0002 for ; Fri, 14 Aug 2020 20:26:54 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C25C85848 for ; Sat, 15 Aug 2020 00:26:53 +0000 (UTC) X-FDA: 77150912706.18.egg10_15185f327001 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id 93B84100EC688 for ; Sat, 15 Aug 2020 00:26:53 +0000 (UTC) X-HE-Tag: egg10_15185f327001 X-Filterd-Recvd-Size: 6576 Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Sat, 15 Aug 2020 00:26:53 +0000 (UTC) Received: by mail-ot1-f67.google.com with SMTP id t7so8993888otp.0 for ; Fri, 14 Aug 2020 17:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=56XdHRbo9k+Mqiix3oE2+ajX+BG6DMvqPZZGvyF8s0g=; b=tixNdcgK+4b42rbbV1u0RJNtmfxWXYFPXMmEtuiTZoiPVRNhfK63NLNQNItaKKt0qU irDv56YmHRUkovanDxgxt9TpyrJ5gDu0dGMI4NpuLAkysQ9jaeJYN5e/oeWpzpU6TWjZ 4hwkVXbKR07KaB16uuzIspvIAimunf7B1eBOfHICpX2UFs+cKR1A3pcch50aSd8d4ucU obkFk/4BOnRLaQUep841rCZ/dsBjIAazO49rnZoxnVe26X/NHcdVXAB2hBJ/dD9ZrNSV 7gL2TYIZpzckSVxb3pGJiNhJJpRLTgukoByesVlSN4fV8ZctLVz2Ymz2dLqufO5Q/MAx Qeiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=56XdHRbo9k+Mqiix3oE2+ajX+BG6DMvqPZZGvyF8s0g=; b=qlCmgshGZ8Um4wl+D675ol6T/d/0e9MEKgWTMLqKcgK4B7l2VDAMJB7F2POe+FGI2f 8dtyzEv0XtaOLZCaJEbbaeYrdl7Z3XDe/nUEyxdzRW58UyNFLG/pss021RcEol9hzpx9 3k96zA/gqARPISRpoP+8YKcF/6hZaQt8Tt1gK1pYKb0JskNS6INjCtqnRkBPRCY3w3ky 7X9Y0yTpJ8SJfLD/GVFHRGCzN+h5e/4VD/a+18tcyfcEHfBLqyIJ836K0Nic1K+VJ6Ht zJFlvKwBAtPy66de/M25JIgKhDQzXAMEvOHwxoldJ9t4d4Cte5x3a/LmT+CSopD2+zZ5 BjxA== X-Gm-Message-State: AOAM532LcEFZBfllkeZWP+9UNU5qOKkTujnKT4sB3EpsBQ/qqKGk8wrj /5lCmm/XJqdhLW8gt50OS+rs4g== X-Google-Smtp-Source: ABdhPJz1ULd9mf33Zk0GkTOi/uDvlRsoh0xCiJzx5JrH5jIYaNNXpeR1yTqNoUjKIOV3Iujqr8p++A== X-Received: by 2002:a05:6830:11:: with SMTP id c17mr3709955otp.287.1597451212070; Fri, 14 Aug 2020 17:26:52 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id z17sm1982367oop.15.2020.08.14.17.26.50 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Fri, 14 Aug 2020 17:26:50 -0700 (PDT) Date: Fri, 14 Aug 2020 17:26:28 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Linus Torvalds cc: Christoph Hellwig , Hugh Dickins , Andrew Morton , Dan Williams , Eric Dumazet , iommu , Linux Kernel Mailing List , Linux-MM Subject: Re: [PATCH] dma-debug: fix debug_dma_assert_idle(), use rcu_read_lock() In-Reply-To: Message-ID: References: <20200814054241.GA719@lst.de> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Rspamd-Queue-Id: 93B84100EC688 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 Fri, 14 Aug 2020, Linus Torvalds wrote: > On Thu, Aug 13, 2020 at 10:42 PM Christoph Hellwig wrote: > > > > The whole thing predates my involvement with the code, but I defintively > > think the patch from Hugh is a major improvement. But I would also > > have no problem with just removing it entirely. > > I decided to just do both, since neither you nor Dan seemed to really object. > > I applied Hugh's RCU read locking patch as a clear improvement, and > then I did a second patch that just removed this function entirely. > That sounds a bit odd, perhaps, but in case people decide to resurrect > the debugging code, I didn't want us to lose sight of Hugh's > improvement just because I then decided that we might as well go one > step further and just remove it entirely. That's ideal, thanks - exactly the sequence I was hoping for. (Another shortcoming in debug_dma_assert_idle(), that I hadn't wanted to distract us by mentioning, is that it assumed that the mapping is contained within one small page, whereas I believe one or more of the DMA mapping functions take a size_t argument, that could in theory span small pages - I guess more plausible inside a compound page; yet it looked like only an initial entry would be put into the radix-tree.) > > And the only real reason I care is that this whole COW and page lock > thing has showed up lately, and I like removing code. > > I'm _very_ tempted to just apply my COW simplification patch that gets > rid of all the complex try-to-share cases entirely (and would also > obviate the whole forced-cow patch). I suspect it would effectively > remove almost all of the [un[lock_page() bottlenecks entirely, but > that code has decades of history and I suspect it's a bit too drastic > wrt KSM and the swap cache pages. Yes, you're right to hold back. I'd been looking there too (but backed off while speeding up the fork was causing the "Hugh load" to "fail": it's the exit that now wants speeding up, to please that test). I think it could well avoid getting into page locking when mapcount is quickly seen to be high (> 1? > 2? > bigger? I never did the logic), but the page locking becomes important when mapcount looks low, yet swap might be involved. We used to rely on page count there, and on trylock_page() only; but there was at least one user whose app went wrong when occasionally we COWed the page, just because something else momentarily took a reference to it, or locked it. Around 2006, bug report from 2004: I did look up the history a week ago, but was interrupted before taking notes. > > It would be lovely if the main source of page locking would really be > about just IO, but the page lock has also become the thing that > serializes almost everything related to page state. Which is why you > find it in contexts that are really not IO-related at all (not just > COW - page migration is the other one that has shown up a lot under > "heavy CPU loads" without really necessarily any IO component to it). > > Linus