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 3F4E8CEACCC for ; Tue, 1 Oct 2024 14:17:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B64F7680002; Tue, 1 Oct 2024 10:16:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B158F280068; Tue, 1 Oct 2024 10:16:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B897680002; Tue, 1 Oct 2024 10:16:59 -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 7C4F8280068 for ; Tue, 1 Oct 2024 10:16:59 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1F54C1C703B for ; Tue, 1 Oct 2024 14:16:59 +0000 (UTC) X-FDA: 82625234958.12.69AD497 Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) by imf19.hostedemail.com (Postfix) with ESMTP id BFAF51A0021 for ; Tue, 1 Oct 2024 14:16:55 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jJdFKhzZ; spf=pass (imf19.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.210.46 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727792151; 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=ph1CXMwrM0Od7OuVQ28Be8BUbBXIPRQeBdm8AFbgkow=; b=DadQdGC0Zd/dcpV71BIe9D3PJA878g3EEaCxqM1DyhM0JR45I69UYg5U+G+Q2aEt4QsdK6 reIl7gcE+vya9z7Q07gBE6K+PnMGhKRfUaTfEhGh+xwEewKvmTAEQx5eqUWGFRsc39fK6+ sNSu9NBBCp62oz1Y0Afro9pd5CPTjh4= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jJdFKhzZ; spf=pass (imf19.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.210.46 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727792151; a=rsa-sha256; cv=none; b=a4NP45tYAp7e79MOv0YRZG7QBbRNWl+Mg55/tUy5AB7s+b9mbCmNIZ38zAk8/WFrvhPUOe E5trcrytBEDvB3LBaclg+SBfygVa9lNYJOBT6BdaoCY6K0xIECvlQYRdbK0yjAverdKrVr Lb4fE5CBKIEEfr8wV7kqCoTZRshHXaA= Received: by mail-ot1-f46.google.com with SMTP id 46e09a7af769-7124395ca86so2297403a34.0 for ; Tue, 01 Oct 2024 07:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727792214; x=1728397014; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ph1CXMwrM0Od7OuVQ28Be8BUbBXIPRQeBdm8AFbgkow=; b=jJdFKhzZTWPf4QQk5HzqmS/CnI3NuXj9rV2bih41CZXH60w5FYtlWiojglJZdGCwAE 27brKwI/kyXZ6d0l3OEvWaw4YTKn/lVssgl6L5ntgWcT9/8e8w65wMvPwlGt36uv1JWx QEGWHhLOM5YCAVseRocEaSSQIE7Axi7F7U6s53JjA1tCIy7jwSddoSefg0E6t3GZZ0vz QdJfTX0igZh+ZokCm1DnwcERFIo5snlCkXtzCBkALRJQoD5aJ7yXLviYySFmNVeFpJUU 6g0B3M5Gtv+zRjBLdiLeYcvx/ooZTrp6ry/2lgtBbVrjugH0BNfOstISj3qz546ahWkr 1mkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727792214; x=1728397014; h=content-transfer-encoding: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=ph1CXMwrM0Od7OuVQ28Be8BUbBXIPRQeBdm8AFbgkow=; b=JpO1N6Zf5rF2TpGbFczqmWCJRj4q3fxQcjd8KsLWageagnjHRuehE3fWbBZcWBiE4X 4HRBaflGhjQ+9zawYtyYO5wLbC5CqRudoTvZl6FYLog8ThxUpVx4rddlV5IqpGZeH0Y4 pBRlAkR7x2kwMiWUaxkRonCaoqYPGNghukMuO+J6MaXxkzMA0zJkVEsYsVXv+KT7Cu3z oD8bDm60wiwsGEVun5/L4O/uKwI2ENITSbfzf1KVhcouXF9WTRPfOMJZOibksU4t8rHi 2UOGc9VUPxAWvgMZEhX6DtswiYqexKZwFPAc3A8V1CdIem8b3YP5BJUx5DBHBqczcOgm VNrQ== X-Forwarded-Encrypted: i=1; AJvYcCVsWhMuJtQGzy7tqR8UNZeLTcOpO66e9aViWQAd7dx+SC7gbhKeN9xVRQr/pPckGZza5tjQKxs3Mw==@kvack.org X-Gm-Message-State: AOJu0Ywc5yw6JDwQgYK3P3vrEoMBGYYTdU5l9khRAbX0QmCDlcXQ2qxV IBvs5pTW1fTdx7YlNH6Nsrfef5eltngCsrROW63imSRgV+94bcOMP+m+o9i6AoC6d5uib39hgtl +y3FluERaBMhvSxot+CZgCZKV350= X-Google-Smtp-Source: AGHT+IFfVSlGf0zJL6/ZI6y0JzFNCuskPx0Gyc8YhUaiOcui23/iIxvQOogfzVfOf5Ay4G0kU+eQQi3qHXBu2AsBY/Q= X-Received: by 2002:a05:6359:7406:b0:1be:de52:97c3 with SMTP id e5c5f4694b2df-1bede52a407mr283920455d.5.1727792214436; Tue, 01 Oct 2024 07:16:54 -0700 (PDT) MIME-Version: 1.0 References: <20240926211936.75373-1-21cnbao@gmail.com> <871q13qj2t.fsf@yhuang6-desk2.ccr.corp.intel.com> <877caspv6u.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: <877caspv6u.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Barry Song <21cnbao@gmail.com> Date: Tue, 1 Oct 2024 22:16:40 +0800 Message-ID: Subject: Re: [PATCH] mm: avoid unconditional one-tick sleep when swapcache_prepare fails To: "Huang, Ying" 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: BFAF51A0021 X-Stat-Signature: ciemy9grxi9ojzszy49s1b97ojmmztmu X-HE-Tag: 1727792215-278300 X-HE-Meta: U2FsdGVkX1/WvSXXajfny9O1LLcni8+UjSZ/VAES/CRYZcbp9dGmBbXJnSC7L1n3Sqlu5XIOe02FAYjWA5ckAmhW3mShjruh/t7xLxWaNlecjeHz1KTsJSGLFPyG74m++lEbS18K1e9LPZaEedgjYSce4ihsuyvllY1kdSEyWri7Vh7E9IQoeCwJlHlBbT5RRcdtwFo4JMz3sAQpNoV3JBCSi56DsUZtiVGyh/LgxtCFcC8TT6BfHMlKl5WFVLdZ2kc6lzFjZX89ogqLq0lxSz3CeGInbOIP0XZoAE/3QQHg2V0TEz7sMF0rmCRt5Pf/LZbPZly10BUCftyukKlzl2Pvl0DuVnX9trIc1nJ/NcPPitrEAGYTJwI53vnUFPRihTXNWgQW2/I60ThncFrt6W6vyqLsMgfyqr4cEPbpIaCeBJCHSVcauFAWLqlR8AMYdW3ZAj0OHc/sDKnui7OUrEvXVZtgX2Or/slQKuy17VU4C32pezUQDD+IarOuL6Dy8MbDhjasO4O2vbnkuT3fIHm2DgId7paSf7mjKramqi8pXlx4rM2QgSv5nGDVyjZMcxXDXVAMtF4FtA39Hlp+LubaBbOvQflytxLdMsx8BvSNqfYNbinzcychUrfVYwVrqJU5dxGxCMpBvv/7Sb4Ew323KNUfrrWZw/z8rj5bqKYCp5+ddX1LQEKTKA5sVHNM2YlQrOl+JXww7/jSS5dhhGFvFXLHcEGTiaaurYOhZfhSuFzVLVCGT5xzuliauF6I6yQkSR2NwiY0YR0BD4gHdGIxypaAPycq/PpEBLoJDSqgEuwvuFNFVDtiQQUdPHmgiWhxjjjEFjzNP7dgTUnNOqNQDCbQ5Le07JCIPgh3dLCy6FZAr+mzGfFU+zgsNVgSOJLD6f6YCYYuV3yJ24CIOyBZN11e5KNe/35iFsW3EPgpu7NjYTFTB2z8Sjx9rDytmYsAqLJhrunOZwYNWVz a+cHOpva lLnQqpSAdqSfu1eSg2N9dEPVXoQsGtOOP/UgUCstt9fQb3jbwlfHUZPSXMactKk1AfhXbOufrJUGgJxyfPY9FU1w78G0gyEwaqFUAND8Id0Lru/1om8bEWd26HMtbBsQ+QTHQXfPmlUPaMPO3f6ZwAHDY8rt4LJhQL+35XifafOjdb5QJRZz7L7ox2al4QojeDKYiQ67LhhIKRoyNNBcU6HgDY19B0WKaRXfMhfK3qEO8UkEtmBa1wfvE2L4sgQBY5wZV80b91O7TTxh/PJ2cwEN1FIgL27nyWbKfYtv2lvqNNheGUKu1vHWKmhzwWEq4V0gaTVtVFJ6h/PDh2OvH3GHSI/EO3Y6l590Yb+qXyJYS5H0lKzKbkPKq/pAMppNtT5NAqozvkUqFxOWgDkH4sD6PBJGaq2bUtc8MHIESl2lyrF0324iQJ1I9gA== 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: On Tue, Oct 1, 2024 at 7:43=E2=80=AFAM Huang, Ying w= rote: > > 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-sensitiv= e > >> > 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 a= n > >> > unrelated `do_swap_page()`, this method is preferable to two scenari= os: > >> > 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 do= ne > > in a separate patch. On phones, I've never encountered any issues repor= ted > > on that path, so it might be better suited for an optimization rather t= han 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. > > >> 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. However, using a global atomic variable would still trigger cache broadcast= s, correct? > > -- > Best Regards, > Huang, Ying Thanks Barry