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 63E15EE49A4 for ; Sun, 20 Aug 2023 12:59:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB21A8D0005; Sun, 20 Aug 2023 08:59:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D621D8D0002; Sun, 20 Aug 2023 08:59:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C29128D0005; Sun, 20 Aug 2023 08:59:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id AEC298D0002 for ; Sun, 20 Aug 2023 08:59:29 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 796C0C0484 for ; Sun, 20 Aug 2023 12:59:29 +0000 (UTC) X-FDA: 81144489258.14.26CD8E0 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf05.hostedemail.com (Postfix) with ESMTP id 8213B100002 for ; Sun, 20 Aug 2023 12:59:27 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=GzRzxnrc; dmarc=none; spf=pass (imf05.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692536367; 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=aYCxZwhLKjTbTVXNyU36rn1PDkh3vGRS5ay1eb7B0IQ=; b=Z9qKIL+mH5Az9u6myf8Gq8RrZGIEYkGloQfNXn9t1r0L9nX2Z4PeUhxhFfLw0D4F1bNZWI Kan3UtCCFM4QQjM4CsvuFrGz/pyC7ciQ374POVpS7u8lTiv6ylu9mtvkD2lW9KYN0XQMya qyKOeovEVbxAToJN68Fp/NLZIykKvLw= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=GzRzxnrc; dmarc=none; spf=pass (imf05.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692536367; a=rsa-sha256; cv=none; b=Py2rmPUkaYt9wzQwIwRYXqyzXhx5lRy9TVjxu0RtSy+MUn8PnYK8WbAwJn7IxAakRs8jRA aTte/cYPLTGMSDuDaCNoYXYRoWV311lgc45T78dgnpVXkDcasYu8zB4x9Ji00j5BjcbQ50 6nfizDXH909+CvIrnGaFWINbkE9rda8= Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-9936b3d0286so328535566b.0 for ; Sun, 20 Aug 2023 05:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1692536366; x=1693141166; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aYCxZwhLKjTbTVXNyU36rn1PDkh3vGRS5ay1eb7B0IQ=; b=GzRzxnrcRHfVeWS900iy3m/imxylcGjCfHzIoVQb2wJr9NkVk0+ArxIa6n6zeOeobo gf9yxo/pOsxpgz7BD/Y44xv1LzspT7PCTwL4VfQP1+SSxjGB7niFF6/abeu4VF801qm/ mePCHGzJBzr+re/2aLV6CVQaJZZncY+76J9Vg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692536366; x=1693141166; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aYCxZwhLKjTbTVXNyU36rn1PDkh3vGRS5ay1eb7B0IQ=; b=HrZW9zvV5fEM0I1SR1Icx+JrtcehVoi7a4yD4q4fgugx3J3mVJCJTCc0zk7qPA5/gu hKndW3kmlO0sjIGea7Oa/h9bCSIRS8SDxp9GHXP2sd3fP/pya3dQ6IfX2Ak5USlKsIDf E2QKor3kSkEDW11QBnQj3R1yxLPsmm6OffpQhWZwtfQydZqrgFHiRYpdMKQ2jg8/Edsc JZnM4Rxplu7/g8QSBg1ZEDKnWO60wdKQJnIGJA8H3X/Gq3nFSmHrnMqjH8kZ3Kw3VSXy V/cxILStgZkLF+0V1RFDCK+48rw3i4S6fD25nThJIG/NpVtUUCFuHWWD/+CKE+8sbubo SBkA== X-Gm-Message-State: AOJu0YyHWjzmvY0ToZZAxp8Y0qsSkuWQN9fX1mtNlEkn8tURIVPJoBt5 l6U2WnxHcQJIfgVVr198mNingChA/sM9MWgwFVledmSR X-Google-Smtp-Source: AGHT+IGElAh0CN3eefTehNbK/+t7gL2AmpsEY5QCr/QNFsHrwt0jegw6ro8K4UhH/G6CNRJ6VgGzDw== X-Received: by 2002:a17:906:5a53:b0:993:d7cf:f58 with SMTP id my19-20020a1709065a5300b00993d7cf0f58mr3331329ejc.2.1692536365805; Sun, 20 Aug 2023 05:59:25 -0700 (PDT) Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com. [209.85.218.47]) by smtp.gmail.com with ESMTPSA id z14-20020a1709064e0e00b0099293cdbc98sm4621978eju.145.2023.08.20.05.59.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Aug 2023 05:59:24 -0700 (PDT) Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-99bf1f632b8so328140966b.1 for ; Sun, 20 Aug 2023 05:59:24 -0700 (PDT) X-Received: by 2002:a17:906:2011:b0:99c:56d1:7c71 with SMTP id 17-20020a170906201100b0099c56d17c71mr2982614ejo.26.1692536364343; Sun, 20 Aug 2023 05:59:24 -0700 (PDT) MIME-Version: 1.0 References: <20230820104303.2083444-1-mjguzik@gmail.com> In-Reply-To: From: Linus Torvalds Date: Sun, 20 Aug 2023 14:59:07 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm: remove unintentional voluntary preemption in get_mmap_lock_carefully To: Mateusz Guzik Cc: Matthew Wilcox , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 8213B100002 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: jcfspbzxo33cop6hm5xcaza17c59x6tu X-HE-Tag: 1692536367-188673 X-HE-Meta: U2FsdGVkX1/Liv/kJSnDjZGa/E2LoMPaGzkkr+0Zqsz/BtOgyI4v7I+m69Cn9GVuGSABAcLFkSGPwfEAMju4Dc3AhlNvaFq7UmTTH9cjXTOsd7Vpc6T9/O/Gl1C01W5IaZy4sj7w5D3taKnbq/FSeviRKsyGCjN110R7pSUSa6FeKm8kfp8ts7mID50/QohWuEkZLeiAZ+XO/WvJmApp4VPfkCjS7eRCiUql+U9EilU5bOuvLFNdiC3YiqhKSYHElGWI0B3AeYyHTDx9dAS50DwLthvvr3y7vMShFaPzYRUp6IMNhfkP2PBDKMelUG3jK9QDS+KMkd1J/mH44hVCkd17SUryjXw8jQsW9869JpGH/lMvtezqP5N/78iVdSE8TQGrqFV3dfTmpRFSONTDMvmRKYpbTFdaQ2tJp09fw6yB30znwmeoO9pL2AU840BMHG3qlXLrE6hG783acncWk6MekDXRaIZXeoNWaIi1KuicdV6w/C5VM/5T4xL/KVEbjaMvXFEINKQtPHqOVmdJHeYlUmW0eLtfdtF34gAUtmbOpgHcdfMNomtFWtFOVPzHXydkK/vo4nv5Y33Fug2SvmwTgP4rwvpn7gIp3m9FnhIi7DGbfg35Efv4Gdp0X67o159vFmmtScczloz1BxGgh+Mhau5V0WlAlOOfKba9LMTxaT61MsgwvFVOGGnFzGoa6v65ZnykNr0G0EqqOxdFmQF7svB+Ca0GEsL1OmolRk4ID4mpNsGS6KI7zdP6UZcwVRKj0ctbvweVp7D4Sg8EVRvQ6+CTMVjfoz7aLaufbKCO9o6mjWjFwSS83uiOXoTOpuduORpRsAZJV6XACWN3LJ+CCdgdNM3DuLOB9w1ZiT+oaUCwKLzPHVnIiTXuREXoXsTS1TQWDizsDv+/rlHjlSDdXWnMhlsrRdHWO7I4iSoC2+xEGy/Y0VmPNuseA4B3gzt7QiODRctMMrBN/X7 uwG3zyVG 9swnRu/rVDbS9HLpRlQ9rkZgg0tasy75aStng3nqwEgxFMRQbylM2UK1xM9ekmoX4vvFCVKr509u9qHItho8Wi/KMqANr4Us6ThChEwatuOcskIMDlkCU57C0qc6NIrUjTbo3fWYtKCsybw5UYC7OaEycYuBIM1keB6wa/rH3rBps14fdx2n+tTLkKQGeNmQbUmv6Ve2zI/CX/pc/hhPJeq+Rt3exS9+cEak58bCx7cNG6Tk7HPHkOylE2k9emuYcp8ehdeIUIC7HfIbLJLWdpGQ0K/aesEP2oWFOWsfcWHowu75vFEoJ+OUJK6G/YSUDYVEa5nFTn6loYtSc/7uK3s72WNsxUHyoZo4m50ABsQ/7Bvm2J9q3/wTXRj/k/++rp2NqUqrBrhf9tfw/TfaSyRTLcGrO3iSIWa0zc9+QNP7I5ZLPP79n1R9xw6I0lPNX/27tODF+fWO55MZjFCRBYNE//HOeYCI8dd789SznshU/gHjIAkkyQjUXvHiNV+3lWUNvBsLZesgT4mBhOBdSWOLXGAh6fqmEK7iMNICPdyV6e+DBcI0bivMvyhJx+quWoHI2HyBc/IuW3WOseijf8/Nj6Bsjay8gXac/ 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, 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. 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)? Linus