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 CED3FEE4993 for ; Sun, 20 Aug 2023 11:37:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E61328E0003; Sun, 20 Aug 2023 07:37:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E11F88D0002; Sun, 20 Aug 2023 07:37:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D01068E0003; Sun, 20 Aug 2023 07:37:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C22698D0002 for ; Sun, 20 Aug 2023 07:37:04 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 79E8D40254 for ; Sun, 20 Aug 2023 11:37:04 +0000 (UTC) X-FDA: 81144281568.25.889A454 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id 4346E100002 for ; Sun, 20 Aug 2023 11:37:01 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ZtMNdze+; dmarc=none; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692531422; 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=xN0fwt/STADs0Ec2XQkK4ix6J4ApFx0uohiaM3xLkWw=; b=2naVbfd9okyDPbozDS9t7HsEE+heilEWzbqVC/UuRGko0r9DvY6URhsmmwRynYljrZDXMF OJ0+uVwqoN0+Z4Lb1RQwEAXTlXASl1QaLO6mlL2/EEsQL1wH6WVpGqAGYNKQjsty/Bm+t8 44mFEezaZ0EM88WkX2CAW9k99YroHK0= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ZtMNdze+; dmarc=none; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692531422; a=rsa-sha256; cv=none; b=wcu5TzYUKJI5TUUZf9XeSDvcJcF0xyBWoQJqF5oaenXPBCmWWFmUa94ecqW9Ay3HQ772J0 TKwXTFv95I258UFv1H9JtrQWO7x6czU+NRzlw+KVodS4KUxLQXcR9nAbPZZxZpJS4IwlLo mne89p7Jo4dn0xR9taC7Cds0j3xw2vI= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=xN0fwt/STADs0Ec2XQkK4ix6J4ApFx0uohiaM3xLkWw=; b=ZtMNdze+d/bULpG639C77uwsGD 9kKjTv2GTLUXyAbNoiUfcSCWJL04AChXWEEPJrpsPo8djuZzrUNp4QNI4ZNGDodU+yvfTCcIi4MlV 8W4IE0eQgwObYpEPwp34OtJa/+T59ZyNAgzdYfQp5tGyyaOM/KVd2pb5FRYecBEgPkmNfgt5YiNXa /68IfgPGghj9NfVB/yoSh2T6O1W4+tFrDaMZ+mIjEbvElgkOF6v6D/3/Sd0YkrWSyuyaz+QMsKVgY 0exvE8sSsfPlGSCYhw4kv149EiVGuMbKvpNyeIon3MdAGrO2Go7eunta/UBE+bkdc5uZMWIRSSBm9 RndrMOnQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qXgjp-003q7c-If; Sun, 20 Aug 2023 11:36:57 +0000 Date: Sun, 20 Aug 2023 12:36:57 +0100 From: Matthew Wilcox To: Mateusz Guzik Cc: torvalds@linux-foundation.org, 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: References: <20230820104303.2083444-1-mjguzik@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230820104303.2083444-1-mjguzik@gmail.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 4346E100002 X-Stat-Signature: dmg6g6dccp5pgp436yrgurtzq7oc65ee X-Rspam-User: X-HE-Tag: 1692531421-917834 X-HE-Meta: U2FsdGVkX1+dRK6hX060gW4FGM20oHC//HzhzAJMPEneKRlHI6JfT15lcxJoIcPvJuwrWNZ9BHAwWpxqo2/WZh7vg6l3GMmEm5jSEMe4zf8YNgD4snfp23v0+SIzm/a1FpEbErzznDK2BUggxXaHKfvpuNXl/1yJscSVo9Fg+qmQTjP+iERcqC+ObTlrfYsxML9kvrvwxdnv+toaLkH9HfLEiPveimWJp20QA3nbk9kERkJxUF6MatQOiJrmbot2+2zxBCN06BP++nfXlOhX/Td3/gbu8d58K9YOsFgvJUVmIr+X8SluXToAk2iKAuBxd2RxoCE/G5TzRBM0t2TagttXctBvdsYy2G3pRLdFEhMiZrU+YCC7XbFOEaCYiIO1Qj6rn94hJkfBAxvBRoqqpbtFbaT8GFLOwGS5KA6E40OIZEcDllQkEVnaFWjnUhqHDH15lbqqsCVad9+oQxQox+SXaYhwTvBPv0tChzGkO5nCknJ1dtjNRRzt/6ljEG4sdcEyEiyyXyH0Ea21+HCGGSKETrZc3HGA/6gKt/iwVvdYujc8nUzElgb6E4ozrjT9q00Bg9MPiJPstKuKirYKfLEUEmOz3gIfopl7kJebtZq+SNw05uGq59WosLY2PAgRdBTbOtAe+k/l6v7DQqM0XOGX9aYm8u11+uvX8tQ4SzzkTmnhhUBgVDgTxOO50ttEOamFDphFF4YGgKga9gFhO46LYlfGHe8mGBAfU5jzvtJo9y1UZeQCABqFWAzZyl9Tn5bw3pchc6M71lZYEu1L2ddiUSMRPqlL3hepamk0Un/9MlHON5MvfJK5IVam1qONm2JnQniMX4LFLcL8Q6T3lXcVKTWGLqT1hAL/Idw5h42KO0apM8XdTh3FvoxNyjfoXpo/9n5LTNI9XUuQBeprE5JNcoGIPeIidhPxGf4DSCCqshYsJLP9ucGgz0lw94jloGR2JLHNon2NFBrr4Br j9irnobI xBiM+napWH4TEOY/cF0pp4mLZUUHTNxh+kvFkpM9+kQk/LhEGSMx0AiY3nfYp3mTqBg/J6SYYJg8kticSxq6ksINufHPxVqkhBYbWhH6SMeOBX9NDlkrjt7xa9EDmsQubvJcIPV6yr1e/xDc0SD8VMH/9ofSd5LNFr6IWJEIc7r5ULp/c3lVkpe/w5w== 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 12:43:03PM +0200, Mateusz Guzik wrote: > Should the trylock succeed (and thus blocking was avoided), the routine > wants to ensure blocking was still legal to do. However, the method > used ends up calling __cond_resched injecting a voluntary preemption > point with the freshly acquired lock. > > One can hack around it using __might_sleep instead of mere might_sleep, > but since threads keep going off CPU here, I figured it is better to > accomodate it. Except now we search the exception tables every time we call it. The now-deleted comment (c2508ec5a58d) suggests this is slow: - /* - * Kernel-mode access to the user address space should only occur - * on well-defined single instructions listed in the exception - * tables. But, an erroneous kernel fault occurring outside one of - * those areas which also holds mmap_lock might deadlock attempting - * to validate the fault against the address space. - * - * Only do the expensive exception table search when we might be at - * risk of a deadlock. This happens if we - * 1. Failed to acquire mmap_lock, and - * 2. The access did not originate in userspace. - */ Now, this doesn't mean we're doing it on every page fault. We skip all of this if we're able to handle the fault under the VMA lock, so the effect is probably much smaller than it was. But I'm surprised not to see you send any data quantifying the effect of this change!