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 D2AD7CF318A for ; Wed, 2 Oct 2024 00:43:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CB3B680043; Tue, 1 Oct 2024 20:43:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1551E68002B; Tue, 1 Oct 2024 20:43:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE8B0680043; Tue, 1 Oct 2024 20:43:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id CCD1F68002B for ; Tue, 1 Oct 2024 20:43:54 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 547461A0711 for ; Wed, 2 Oct 2024 00:43:54 +0000 (UTC) X-FDA: 82626814788.10.C572CA4 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) by imf22.hostedemail.com (Postfix) with ESMTP id D1B7CC0004 for ; Wed, 2 Oct 2024 00:43:50 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=NeVJWx6g; spf=pass (imf22.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.13 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=1727829663; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=h4T0B44xY0G0Vdd0Vtd9qf3irdciiztMUMjWoHvth64=; b=ZhZn62/brtN/N6R1zN+OOe688p0g/Bl+rkS+RdwAErO4+LQSwRV+wH2BWJhmQ13GX53TOS vDuBDQMRT9LYgAnVBSAeX+xF1azFU/kGbUoHnbxeiVqXcCDdihkvNTcTuKHNdNKpngUEJQ KyGNnNcuDzYmzICrN/0kOzdv0kUlZSY= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=NeVJWx6g; spf=pass (imf22.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.13 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=1727829663; a=rsa-sha256; cv=none; b=FsRB3Faj/2B30wvUKUj/a6sG9i002LILXGsvlsu027z7N69u1Rcyo02KgcizWO9GTXp9JX /b8fOMiZHQv+dYeYpGwf6Ahaai6fOwr8/NbRvKi0AtBkG2jBaIxA5QtDUk/Cwy/QIMZyUA 1E8eC0CJiV0uBainoFU7AdlXnW8VOhs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727829831; x=1759365831; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=tcXTdEFpw72XF6DZDqbt/wfDaFhysJTtY2A9zo6XIT4=; b=NeVJWx6gTx8MDmgDn4G9bw3wAVxeBpju3Dq7gX5FE2b+KKUlwGBOAJSq twsqWCKStfUGPFVjZ5witvdyvPGxXcMEw6sYRAualxzmzs2XIszuDKzZz wiWOcZ2MFgo2yzWstABn5iAn34c+KMAWaFcWDydsr5ZBhwjjjCwxQrdeM GSVsRyfg/gR/8KbtPtIuUS0Y8vkJkVi+7KZPKE3paa6HOZOSK+lxKZlFG FyeGMyzha+OU18LFA3Dsh2y09STlC2lS6yMOI//f3CFxxvGt7BJUbY1Tn aqM+8uPVs3/4xaxSdgMtd6AStojp7hWnvNYl2TdztOwVGmXAbveVqMWc8 Q==; X-CSE-ConnectionGUID: LICuLnjmT++LY1qEthQYkA== X-CSE-MsgGUID: xQOX0lLvQYmrg3NhGyI8kA== X-IronPort-AV: E=McAfee;i="6700,10204,11212"; a="38120606" X-IronPort-AV: E=Sophos;i="6.11,170,1725346800"; d="scan'208";a="38120606" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Oct 2024 17:43:50 -0700 X-CSE-ConnectionGUID: h996thFRSziLfQDCq8t10g== X-CSE-MsgGUID: NPFLuKCjQ1ietow+3qFIag== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,170,1725346800"; d="scan'208";a="74166951" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa010-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Oct 2024 17:43:46 -0700 From: "Huang, Ying" To: Barry Song <21cnbao@gmail.com>, Kairui Song Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry 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: (Barry Song's message of "Tue, 1 Oct 2024 22:16:40 +0800") References: <20240926211936.75373-1-21cnbao@gmail.com> <871q13qj2t.fsf@yhuang6-desk2.ccr.corp.intel.com> <877caspv6u.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Wed, 02 Oct 2024 08:40:11 +0800 Message-ID: <87y137nxqs.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D1B7CC0004 X-Stat-Signature: 1ohmu3jygqcsduxh95rpqu1ge1wc8z8q X-Rspam-User: X-HE-Tag: 1727829830-725160 X-HE-Meta: U2FsdGVkX1+2Wcv/foceqcmsY6/Nfw4gCREVsEagm/KOesfIf2Md0Qy2ON499H7TSes65fb7Ug3BEMFpEGxMxGbjUTgOjAk9IeIEFUlqsvm9OaEj7cvkF2P5OXngBFH8yGHyhIvtxCVVP2FjVpLxs5J02QHT0qsCo9fZXz2q5un25PKATsgT5auMeTK2+KhXsHennTlyA8cAoBt5zjeYv7op8teYpumlZXYgbl7GDhbzOCtxIEgYCgRUp+X7iFPS79FzSIyHNwwKOreUouvnBjsu9fKIQPi9NZzaAUghyYbEQ0inl4eKBbscy7YOAz9F+oOJwzeiZQMNG5iOBZ7RJQ4KBNc2UeVXU7a5HCWmWFICPxtvxggCXjXynUtVP7jz2cGdyTzeJMlcidkAnRMg1cHVJ4k/nNZbNiGdyQgDBi8ngOBiQC5APMWtqCx1LHd7oUi3JHNvMGmJQtnm1wsRSaJdvFVPqKpiRR53vOg4vc8+6AoWaGSToUsf4uRv0JNKsmpmkJpo3t026X5vnpwOPl5Mgglpz2kTkMgySohVtfW8KTqbvqyQhenmi2a2aSIjmOaoT5LQjY1f1HlKCjhSPjzLkziHW2JgGb0gB4UmKnvM9r5EK50c28BlS7v2e5gyU9dHuMWTNmn5PM6LTmaArRzN4hVrEVLKsHggm0ZYbKDND96Zy4vLBC/FcjakIP74M0+fOBY51DZrzuklISaveptVswppkQ1Azx1BFmb/QOgyBUyUd75aoJHzg2b7d5YFnNZwk5qmQAHtQ1NEeFQA4gVufJGHTmT3EhmvNSgqCU+eEnoO62lJ6SozIYl/5lj3KpaheUSywPE3q2QYzfOHrsMdZlidOHcmq9bJhq6rjhfWEdgF1VBMiOOq+10QGc9WlIi9izTdOURAj45QX1n4eFRrYd0GV7G7f0HE+9aLY3bG44NfmJBHAV9jt4O5q7VNyXMSzO8XmRV+zJ7dvCO xSnjRdfm +sJbW6wDd1DY1loy3A8rBE5BNpYt2eAUxu4Aq6MclyE6vcpV18c1P72IYiTWx8ovkVj8PwdwPhrgT2LT9Z3gVsaRkyCjIM7/dnPHES6ZWSmmShdq4GUqrpCeuvKsGLnABgER2aWgwGJH4ok+PwPoZHvooAGUdgK4cYSFTjiGfrEigLVH5ZSxE+I+h4LxYQM/ieYgRss6szX61FpDs8uRawuzWT0cZCcI642zKMgt1HRlJZuKfU63TbzsnmTULmiDLoQpE7xdyhxnHOLZP2+ftsGvNDvuJ8/aZ4DwkZ/gQ8RfarAOMWLWf7HWeX8pAlg97RuZNF+ihO/rwXdt388RPFdYWKhF81vqO5WevAKqfzLcqt5aAKVRFQ3QjRA== 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: Barry Song <21cnbao@gmail.com> writes: > On Tue, Oct 1, 2024 at 7:43=E2=80=AFAM Huang, Ying = wrote: >> >> Barry Song <21cnbao@gmail.com> writes: >> >> > On Sun, Sep 29, 2024 at 3:43=E2=80=AFPM Huang, Ying wrote: >> >> >> >> 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-sensiti= ve >> >> > 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 scenar= ios: >> >> > 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 >> > >> > Hi Ying, >> > Thanks for your comments. >> > I feel extending the solution to __read_swap_cache_async() should be d= one >> > in a separate patch. On phones, I've never encountered any issues repo= rted >> > on that path, so it might be better suited for an optimization rather = than a >> > hotfix? >> >> Yes. It's fine to do that in another patch as optimization. > > Ok. I'll prepare a separate patch for optimizing that path. Thanks! >> >> >> overhead to call wake_up() when there's no task waiting, we can use an >> >> atomic to count waiting tasks. >> > >> > I'm not sure it's worth adding the complexity, as wake_up() on an empty >> > waitqueue should have a very low cost on its own? >> >> wake_up() needs to call spin_lock_irqsave() unconditionally on a global >> shared lock. On systems with many CPUs (such servers), this may cause >> severe lock contention. Even the cache ping-pong may hurt performance >> much. > > I understand that cache synchronization was a significant issue before > qspinlock, but it seems to be less of a concern after its implementation. Unfortunately, qspinlock cannot eliminate cache ping-pong issue, as discussed in the following thread. https://lore.kernel.org/lkml/20220510192708.GQ76023@worktop.programming.kic= ks-ass.net/ > However, using a global atomic variable would still trigger cache broadca= sts, > correct? We can only change the atomic variable to non-zero when swapcache_prepare() returns non-zero, and call wake_up() when the atomic variable is non-zero. Because swapcache_prepare() returns 0 most times, the atomic variable is 0 most times. If we don't change the value of atomic variable, cache ping-pong will not be triggered. Hi, Kairui, Do you have some test cases to test parallel zram swap-in? If so, that can be used to verify whether cache ping-pong is an issue and whether it can be fixed via a global atomic variable. -- Best Regards, Huang, Ying