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 95F4BCF6491 for ; Sun, 29 Sep 2024 02:43:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EEFB06B00BD; Sat, 28 Sep 2024 22:43:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E9F4A6B00E1; Sat, 28 Sep 2024 22:43:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8F8F6B01F2; Sat, 28 Sep 2024 22:43:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BB09C6B00BD for ; Sat, 28 Sep 2024 22:43:22 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2D219816FE for ; Sun, 29 Sep 2024 02:43:22 +0000 (UTC) X-FDA: 82616229444.09.70F30B3 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) by imf04.hostedemail.com (Postfix) with ESMTP id 6C4A540004 for ; Sun, 29 Sep 2024 02:43:18 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=MVzGq79g; spf=pass (imf04.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.17 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727577634; 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=TdAjSVp1HKIxC9lSXoVgtOhjxeg2civIlwijpmtIxNM=; b=FXsbuJoizCG6qk10toPnIeXfcUetnvsO5jtauYmkgno717EtANVTqAur9IqcMgh3+qAcYS Sg9lbR/BNy3a4SEh4txiC6jCKv8PpzZQ4pDxOnlT+P80r/VPC1pENXb8AP1Mk2ZbkSE+/N DdehC3gl4Pu9iS7aKDY6i7WO/L162ac= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=MVzGq79g; spf=pass (imf04.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.17 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727577634; a=rsa-sha256; cv=none; b=3tYDDGw4f/wIBcDs05HZyWt+JETNHn6K7MrrSFViFIR7YLgAXpc9ogWCdLFAeMb5Jm9xwV 6SnSkjKTwm3KQLCYUC9lckPH83Yt1elZkJM7K0akEVNbMF11DV7YBXRfXbyvInIS4+ZMqK IJ7P4Mo2gxOA1N7be6i7Nd5gD1gq38U= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727577799; x=1759113799; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=g8uX7WlDZec4SnDsF7a5R6meNAivR0E+SHDO40mm4IU=; b=MVzGq79g7Z6VrSGdf2JANDxjXXJLNm6kpokKPZLbARb1w4uBcJj8Y5FV y/xPk3BExFLX/iQt1hy1I7xRjq3hSXhfXDe85DEKX/ktNCpIyzHWvIx4z L2QmQSqjR6Cz/+QxQ0cZApD6GbeM8ysnGU1bhdCBcFRxRbVdUknzAn+m5 nomskHMFkrxqnHOM/gnhNwDlrpxize2ydFkIdmuv6TiA1W7npThp55ZAH uZ7xP/9X/XxPZyrFY3+TqC/Fu2yAiFPYQS6pH/+Kxhb6y6CC507JtvntE zxlsLYAZidW4bSru+/BFV0bkOTIOb+VDiVKeeXsnPQYsVOdL6mGuVyqw7 Q==; X-CSE-ConnectionGUID: bpsc0I/QSlG8OL+zb+g8TA== X-CSE-MsgGUID: yh2PJLrPTVqwkdi6mvBLSQ== X-IronPort-AV: E=McAfee;i="6700,10204,11209"; a="26820098" X-IronPort-AV: E=Sophos;i="6.11,162,1725346800"; d="scan'208";a="26820098" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2024 19:43:17 -0700 X-CSE-ConnectionGUID: 4DrfJr3eTpKPJm6yD4yWqA== X-CSE-MsgGUID: rHlnvx1cTy6q6al5OHj5fQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,162,1725346800"; d="scan'208";a="103713140" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2024 19:43:12 -0700 From: "Huang, Ying" To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , Kairui Song , Yu Zhao , David Hildenbrand , Chris Li , Hugh Dickins , Johannes Weiner , Matthew Wilcox , Michal Hocko , Minchan Kim , Yosry Ahmed , SeongJae Park , Kalesh Singh , Suren Baghdasaryan , stable@vger.kernel.org, Oven Liyang Subject: Re: [PATCH] mm: avoid unconditional one-tick sleep when swapcache_prepare fails In-Reply-To: <20240926211936.75373-1-21cnbao@gmail.com> (Barry Song's message of "Fri, 27 Sep 2024 09:19:36 +1200") References: <20240926211936.75373-1-21cnbao@gmail.com> Date: Sun, 29 Sep 2024 10:39:38 +0800 Message-ID: <871q13qj2t.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6C4A540004 X-Stat-Signature: t3bfcjo8yccbkjjpeeqpx1q7ir1dejed X-Rspam-User: X-HE-Tag: 1727577798-638249 X-HE-Meta: U2FsdGVkX18ojvy84P7m/anq0pbILTaiw+Vzzizva4WS2J0fV0COUNs6esyqlTJRCoHiIkF+WNv6KRdbA0mej//4NFHxFvha+Rj9MdTWKAnf7YpNlqsrgLFNlIYgKUGJvSJuspZUmleGeOnKK5jviNP1ezH7zC8tJTRc8Nz0bQimONwKDZVl4dsOWuG+IXZgPLLdc+Jv5NxKOA+jZKP1kSFnMJsaLwX5dk0refpTo9DoMRsuVce6IUWEGzfu71vl5yH73rRag2mPMW7MqLbo9wZjdkOZcglRSRuZxHzw1EJOiAr0El2rUon/U9HEtytQnHDfjV15nQGiceUOnVSW0d8dgNJXyjsjWJw9DwwP993j/7vtUvyhl2A3x9e0bRGP7LACs9awgwzZVf8VTrbP2BF4EAjS9duwX2+SYrry2f0xe3gU4XMDkMJjeROnRLQT0HDgK8smGygs9PTkQV0L9QbM/CtuJXj2GFC2DgiK9WA90RxjIpPpm7hbxad9th2hojUXewNjuQAFsICqQtRwrhqlLpfCWiP/CD+zkWpDxdRiQB4JHfDohQgzUSe8zXJKbc/RZH/PEem/Z4VwNPl/pXL4tU7LW6jl1camA7suVnliqJUgULIqLd+9qy5OSWSwvvY+6x7yJxzIR3PwKtl8Y9Zbd1u2B4qZgJsVUXAmxO+62FR3yVF5h35Ud0fTxhEvpLEqKX/GOxmXl8Fjj4Zc4G6LHC19iWhpF9W2Az9T7XcG6eJZWICbIB0Hi9R+KhzPrfrnGIx9iItIe0k414OdV9zzMK376iGKct0gN45RUhqPqo4TEstUZfYnxviHMJ7JBS781WRgARotZY5aFEyxZwLaZgxYVsqGnVy9B9Y/wY959Y27cPTltgZhFT/l3QVW8FbqBBMs4kq0ErSa4dMQbIPUlQ06nUdIwgFomIv9okQFMqtQm2AVykIHtBKc2ADLkD/83cexHeEvGpCgVqQ 5Q0HH4XL 6Yb3rnhvQUATDgLKYD+v/dajlYbIiZ9gRDWhWJu0Tc8JHbfAt0acIETrspdQUwv1RWVRdBdajaP7N5raVwtgowHSyiuWCF71iFcgjNBsZcXW//5yG9gtjll3KO1dVjrTDMno9FT0fvUqiZyq12jlQYhgCbl1LkDw9aQW+9hC2TGx/usifFThWfZBI5XxkEdx0NwY6NcdVkq13wabNpKnELNzfCS2wzvUUAeA4XgK18NkhUMf+Jn0xG8g28N9ZE3eHEDJi613NkZb57C8= 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: List-Subscribe: List-Unsubscribe: Hi, Barry, Barry Song <21cnbao@gmail.com> writes: > From: Barry Song > > Commit 13ddaf26be32 ("mm/swap: fix race when skipping swapcache") > introduced an unconditional one-tick sleep when `swapcache_prepare()` > fails, which has led to reports of UI stuttering on latency-sensitive > Android devices. To address this, we can use a waitqueue to wake up > tasks that fail `swapcache_prepare()` sooner, instead of always > sleeping for a full tick. While tasks may occasionally be woken by an > unrelated `do_swap_page()`, this method is preferable to two scenarios: > rapid re-entry into page faults, which can cause livelocks, and > multiple millisecond sleeps, which visibly degrade user experience. In general, I think that this works. Why not extend the solution to cover schedule_timeout_uninterruptible() in __read_swap_cache_async() too? We can call wake_up() when we clear SWAP_HAS_CACHE. To avoid overhead to call wake_up() when there's no task waiting, we can use an atomic to count waiting tasks. [snip] -- Best Regards, Huang, Ying