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 16972EE49A4 for ; Sun, 20 Aug 2023 13:09:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 839FD8E0006; Sun, 20 Aug 2023 09:09:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EA3B8D0002; Sun, 20 Aug 2023 09:09:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 700E68E0006; Sun, 20 Aug 2023 09:09:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 61C9F8D0002 for ; Sun, 20 Aug 2023 09:09:04 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 121AFC085A for ; Sun, 20 Aug 2023 13:09:04 +0000 (UTC) X-FDA: 81144513408.09.46C1254 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf17.hostedemail.com (Postfix) with ESMTP id 225A140022 for ; Sun, 20 Aug 2023 13:09:01 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b="Rpu5V/q5"; spf=pass (imf17.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692536942; a=rsa-sha256; cv=none; b=SDllotZE1yZ4xg6xfroJq4qIA8Nizs4baMGSGPeq4SdqsC0Ja3fwXzcUcHJQ0958hoYfbr c9Gev0jEEEmbZW5meztI4k05qJ/w5R42Fayy2BklQCR86n/kjo2GpAKBPY4tPzU/xd9Zaa 8Ex7e0lgoVfsschCvfzUR+lR4T40XIQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b="Rpu5V/q5"; spf=pass (imf17.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=mjguzik@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=1692536942; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=3LZ+oES1zsfNlKxhCEQJA4MvdY1kIWFy2dYtj4VC1s8=; b=yyi/qOG6is35w6d6YHRjsZRP2cUUDSccm0TjyEBl8NmvEXJKRWDlu830LvDG0b6rQe7KIX 97PehpTZR+QdPtq5qjZxMgvlyBoBXZEETDnrZKPvI2JNjQ0YSitBKxGsSkpiJlmAPnGQAO qvLXeTtQNvOSIl/8YrzoaiB6eTI5qcA= Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-4ff91f2d7e2so3329856e87.0 for ; Sun, 20 Aug 2023 06:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692536940; x=1693141740; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=3LZ+oES1zsfNlKxhCEQJA4MvdY1kIWFy2dYtj4VC1s8=; b=Rpu5V/q5Rj3FAFJgbIFk6XfWl+O4qv73wk/unM9kUZT2aU8w/Uv4eukCWPYM3rl8UP TcgegFpXDpMG09ODb/lJ2z23RT6kLRv14N3yX9OO5GRM4ECOPDEn5uvWmAr5Cu2klai6 041vg2eb7N9c3VjvmUWBFyRFpWnmzTBTOjaFjNuYExeD27jqs/bHTQ1P+09tJ2JC8pdD knPEor3GKvn7E8UT59RJV/9ucrEz5VbK9dt1v8OZXmzoTN7fTNNNTG5D7AWEN/89zr5m QEJFDxa96GcDjp8OixEZliiKAdA9vlDjmWXl6TMddYe1uvoVFtVr1lWJmKGVW5cnqyxm l2JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692536940; x=1693141740; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3LZ+oES1zsfNlKxhCEQJA4MvdY1kIWFy2dYtj4VC1s8=; b=I9DwtFz0M1qIvtBM5GMg5sf4R4NVYlKCXCEk3cm5aqSB0C0E/Wht+jU5iidAPmwKn7 oYo9+7TBM1AeNO/6Bo35OliFNIjVE6o2w1yx0uSwSdH7Ww7ZJjpzPYGhZmity046DMci 3Xe/EeNuMjbdveQnUZ8/YyF2iHQKHpzDyYib9PKwixCgYYUdYklXJD0NnSuislm39rws 7XzusvYEDO0A3g4K87l5fDPmXbdK8FqiGDy7rI/b2qcHli7IVuOaivX7/HNUIoP+mGMV YfMQH4z3OeX5Uqcv7mEPcW6Muy8xACu3zaqbpWjvOoHLkwx8KGyzYMbUe7FSbpkPFUIV LQsQ== X-Gm-Message-State: AOJu0YzS6nfVSnLKmAypps5kPpfgCUICNosX60HbDvZRjakOYVo5E023 vIqRnUxbnChYz3oGDJ2Np04= X-Google-Smtp-Source: AGHT+IFTG+Uf/j3nxx0sFZqGDD5S8oGs3q8smizkUS/mb+as4m/zVf3PT2lLTMD/Y3+NVynnaGlSQw== X-Received: by 2002:a19:5e49:0:b0:4fd:c844:6a43 with SMTP id z9-20020a195e49000000b004fdc8446a43mr2037685lfi.43.1692536940067; Sun, 20 Aug 2023 06:09:00 -0700 (PDT) Received: from f (cst-prg-27-89.cust.vodafone.cz. [46.135.27.89]) by smtp.gmail.com with ESMTPSA id v5-20020aa7dbc5000000b0052241b8fd0bsm4302636edt.29.2023.08.20.06.08.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 20 Aug 2023 06:08:59 -0700 (PDT) Date: Sun, 20 Aug 2023 15:08:56 +0200 From: Mateusz Guzik To: Linus Torvalds Cc: Matthew Wilcox , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm: remove unintentional voluntary preemption in get_mmap_lock_carefully Message-ID: <20230820130856.j2wbfe4z6iem4fis@f> References: <20230820104303.2083444-1-mjguzik@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 225A140022 X-Stat-Signature: f15d7ttwbwjf77ztdi4beouwk5rc5n36 X-Rspam-User: X-HE-Tag: 1692536941-195762 X-HE-Meta: U2FsdGVkX1/HrIZYBh3hlZbc3cXKxO4BT3VccMu6ML9UlqnbqRd3BjQ9pjtw6HCGF3JgK5/32+JxY9wHdef+fHmiXqYBPCv5u7gYzWCMCNKDtDlZmpepWt3Gx5ZCzNPBjJQtetAGWxMGlnI9DUv7S98N4t0drTF2L1ZvcLRxBfHNPpW4baE0OgjpCGDYzYlyonNj0z12zoF3Es0htQIpqn9ok26GTERMVlBKJ4qlGp2kCohxHY4pFIeCLx2gFILPe8sIUMUiKogC4myL2QpzyVdIH5NKU9ZAdn6QOnMNaHolv6o2RPFX8rmeMyAn3ll+hMcS/PxoIG3wq6pF8JCBiziWwhbcWWRZOHd7I1YbIl6b70nFaDqJmAtWupT0PX9hPIVIbz3Rjw8S5N5yBVcJZcALwHUYdbmlGR8U2xhHGKX8vBvD4kIiXe7s1mlzvBh+J8Xj9sxmLSnoItFNFrADj/4Nv77o9N9J0pku+aAAInczcx8tBqU5H4OhS113qJu1H0ETBq4SwnoAfPmmuMadRfU3+38TS7NEqPzIJSlU1TZwtnWU+61AlyaztE2rl4DCuNuPaB1Yl/q3KLV+/d9pjLJOTDEQlTZJbtUb7ieQl43UynDIP96GDH2ttl1c0Gkn/LFFu0NBa4AnWStwHiPP0/MPGmyIOFVwAkxOqpaWMGKp9ta+PghOor/KaxgxjbEnDb92CVx1AshvzT8A8wptC3MoJRLYwdc4s8wsup1dTtuWcANDO767Q7kNfkrHUaz4/Zzv0i2zhAfUj2RD1yYjJoc1N5NPs5eQk7+dIjqDkRFFKryjzfo8lxTH2hJsck/FOQzscQS6NA6ZsMT8qT5gPTU8dnY98/VaubhO0J8WT6M2si4MXLe+4AxjVq8GvfEp3WU41xWtiwltQAjoY4goCYX6V3phHXXrRlt5jDixdFx5askRjWE1W3QXOAuApYmNMnJf6yU2EJhJFbIpD79 YmxE4fEL iGnPUpcA8HaaOmmlDgWFucHxNS+X9kanmY+J493Lvo8r0LlHVJPQEInR4yzO7PbrjMrCYNBU38c7Ae4uh5CkC3I/3eEGSF+nphmbCOtUiOeBIQwMcoibfP+TlFBtQI98bijuiAkLq3ogE8D1+O1ZXoUoC5mA/dngBI0lYPmmF/XMXSLEB2xF0A3trj8kqllUZMrU0yz02IewtZ1uDm3Keno0Xepw4PxZGUbS66Br3WLGUKI83zUdvm9nRs4jUOvIC/VdgbDZIruGja9Oy3lXnQ8e8zhmw+jAl8CejH81j90cbv05hMBCbFB0ZhMxEOWOJw4NOW0DzvNGi2R9K8CQqRAqWJuCdGgc+9KKPHLbg8u9kHFCLvJlO7mJuzpjLPE+NYMsrCCnILywYF3ssd8hCY2drONe1OS6Yh0PN/+x48LrRgp2sNqe898X7MgtztvuWTYWTuz14ni9ROU6GhcThAnWg/JUNsCk2gkiZEkrA5Oge1Og7T+0jCR6x5JbReIjyGgyZ23AUf4ebD4mTfx/gVnUxSg== 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 Sun, Aug 20, 2023 at 02:59:07PM +0200, Linus Torvalds wrote: > On Sun, 20 Aug 2023 at 14:47, Linus Torvalds > wrote: > > > > But without that odd ifdef, I think it's fine. > > Another option might be to just move the might_sleep() to the top, and > do it unconditionally. If the trylock fails, the overhead of possibly > doing a cond_resched() is kind of moot. > I wanted to do it, but then I found this comment: * For example, if we have a kernel bug that causes a page * fault, we don't want to just use mmap_read_lock() to get * the mm lock, because that would deadlock if the bug were * to happen while we're holding the mm lock for writing. I figured scheduling away while on the way to OOPS/similar is not the best thing to happen. > IOW, the main problem here is not that it causes a scheduling point > (if the kernel isn't preemptable), it seems to be just that we > unnecessarily schedule in a place with the mm lock is held, so it > unnecessarily causes possible lock contention for writers. > > With the per-vma locking catching most cases, does any of this even matter? > > Mateusz - on that note: I'm wondering what made you see this as a > problem. The case you quote doesn't actually seem to be threaded, so > the vm lock contention shouldn't actually matter there. > > Does it schedule away? Sure. But only if "needs_resched" is set, so it > doesn't seem to be a *bad* thing per se. > > It might just be that this particular scheduling point ends up being a > common one on that load, and with those kernel config options (ie > PREEMPT_VOLUNTARY)? > I did not cause a slowdown for me and I did not say it did. I am saying down_read + going off CPU, should it happen in a multithreaded program, is going to delay any down_write issued by other threads. And that going off CPU here was clearly not intended. As I noted in another e-mail this is just a side thing I spotted while looking at other stuff. I don't find it important enough to discuss it any further, so as far as I am concerned you are most welcome to take any of the 2 patches, write your own or or leave the code be. [I am going to post other stuff later which *I am* going to argue to push for ;>]