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 9ADBAC77B61 for ; Fri, 28 Apr 2023 08:17:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0352A6B0071; Fri, 28 Apr 2023 04:17:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F26EE6B0072; Fri, 28 Apr 2023 04:17:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3D716B0074; Fri, 28 Apr 2023 04:17:46 -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 D7EB36B0071 for ; Fri, 28 Apr 2023 04:17:46 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8F9CA402DE for ; Fri, 28 Apr 2023 08:17:46 +0000 (UTC) X-FDA: 80730096132.17.E66E37B Received: from r3-25.sinamail.sina.com.cn (r3-25.sinamail.sina.com.cn [202.108.3.25]) by imf09.hostedemail.com (Postfix) with ESMTP id 6531E140002 for ; Fri, 28 Apr 2023 08:17:43 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.25 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682669864; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nI9AmVZfGeBtXXi6ukj3CDcCGJgQGj7k/IEI1EnmF2s=; b=eRu6+yBJk7YY9ztTAT2TnXRV8IZ0fhhwE8m1Xd8LnTJpaP5vEqn9bvox4DBSIr6h6c5Vi1 7OhhDARwEABjfeAZA1cVrr84uWCyYR+749I7Zt7N2SMiz07j4J1AKlouq93duy2oOtqDqw 1SxukbUz0luTVUbNTbiku8uDi90gnEU= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.25 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682669864; a=rsa-sha256; cv=none; b=LYTu9EMnAxbP1xadvs+5IKq7YMlZyT4RQ+hFPtZtjcxrgTonvhEyLkLUPmfGQQ5h+WnLlw gBMv0L8gO8WDL5J4Yh0Ic6EgHjmemMxhj83hvM7XFIV8Gf5n3l3PsHOhexECVfEUYEwsc1 rChtzqdHc6vvZ2peQS9OVEzEH771Cxg= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([114.249.59.75]) by sina.com (172.16.97.23) with ESMTP id 644B812100014F5F; Fri, 28 Apr 2023 16:17:39 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 34599831458195 From: Hillf Danton To: Mel Gorman Cc: Doug Anderson , Matthew Wilcox , Alexander Viro , Christian Brauner , Yu Zhao , Hillf Danton , Andrew Morton , Linus Torvalds , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 1/4] mm/filemap: Add folio_lock_timeout() Date: Fri, 28 Apr 2023 16:17:28 +0800 Message-Id: <20230428081728.2597-1-hdanton@sina.com> In-Reply-To: <20230427094847.fmj4ju4spwkawtez@techsingularity.net> References: <20230421151135.v2.1.I2b71e11264c5c214bc59744b9e13e4c353bc5714@changeid> <20230422051858.1696-1-hdanton@sina.com> <20230425010917.1984-1-hdanton@sina.com> <20230426100918.ku32k6mqoogsnijn@techsingularity.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: u6kxrnhjj56y1rj566cho8w5ye6wz9t1 X-Rspam-User: X-Rspamd-Queue-Id: 6531E140002 X-Rspamd-Server: rspam06 X-HE-Tag: 1682669863-888610 X-HE-Meta: U2FsdGVkX1/B1tLPgbfPLmLecKViTiaNUOdpQ4CkL/5AVKgsk7Y0ciu7+FuGS/bQiREPdrEGDUeycjXUArIi2Xz9ETeU3xARbhim8G6Fxd2tev/C60fq0SnGdEIVwrV3GOdPWV+Lh7ToSDyM57HkrdYIozO2weLHAIBK1RayJ8mmNNuMgWN8HWn3pXzCtQb9CfF2pACY1ypziUjk83JosvmGKM7Txh4gYLDnDZDmxcFRS3BFmkvUpFWmU5Pz1VY9WyrnaoFxVmBLBYcfF25OBHsW+ndiWPgxZTL5FiFgohis+j4naStCDVY+Cmn08P4d4mPIJY1g944sYY6T4p6dxm1HTMJgrdKri9DHv/NBOiI4q0kp8X3E+w3D35FXAdetlFWA9FzGJENCHS0BPReayEVzbr6twmc36EPyT2zMreGYQyKndyVvRuGFQxtKrL8me8OkdN2/fnL+DkAe/9MqAQMVm7oYLm2O+c3u0UJydpZDMhyZLfpg2EoLbGTxJBk8hMtBQbXPtp4xUamRvc3wHaWG2ecNsS6LhmKIk/VhSjvnpyIPvMvJp2q7heH9NmWylgbBCZA25ney/Cv3Dgw8ef4i0PtQZtV4K/6f4u8Qfzmz+0zQk1LtUDhpmSuvhmZ/cz2CE2a4OZfWiRXvpuuTAJnpYLjG313R1Q/2BrmGCNEl66AKUzQ+uGiYrbwt+0eJ38wGF1dx6NqRH0XWuAxXpQNVCE+eprZgAsErt/8Mpdq/JEKNJtcV2KT40kkMkR2ihv2G2VDvo0p+rOZpGoImcd4jxkyl71RL4oWRssdPmbmzqf3xjs6BpFBG1mvOo8SLPG118R0XYg2QCgBYUjcM+E49BSKJK1hcwhQe7TdNlA5rMU2hJZTI9+fHjH4J30yPN18PgTrCVvuahsZTgqqozJyO3yd1lTtmCY4oIl3w6Ux0n4naD9etc8KduNfd3lktBSAbmxXmkd8GQY7F2iZ COrBzsi+ 6zmUhrfRyD9ACnWwe0DQ6g6rl7rgcoEWDuw1FezBYbFwMTprYB5FfftoJQIxtfJyFIMOLjb52bf53dWImBc5EbN0c/DEUgw/x4W0qakT8I9dIwO6lFvHPI9M3wE6PZMz00CnbU8Aimgb5wnMBnxHAkGuLL9eAPnh1TG2GwWxAXOwVLhICIYbbcC3QMUTvcBY0hLN0drjdfo8jbAfk0tO4prW4Zg== 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 27 Apr 2023 10:48:47 +0100 Mel Gorman > > Matthew's suggestion on checking uptodate is a good one. If he's right, > the problem goes away. If the problem still persists, I am willing to bet > that it's mitigated a lot *and* it becomes interesting to find out why a > !uptodate page could take a very long time to lock because it's possibly > revealing another real bug. If the idea does not work at all, the timeout > patch still exists, add to the changelog why checking uptodate doesn't > work and Linus spelled out clearly why it should be ok in this specific > case even if we have to watch out for bad users of the new interface. Timeout detects slow IO in this case, while hardware vonders provide IO speed info for free, so SYNC_LIGHT likely breaks with slow hardware after adding timeout.