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 E0526C3271E for ; Tue, 9 Jul 2024 00:57:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6193E6B0096; Mon, 8 Jul 2024 20:57:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C9646B0099; Mon, 8 Jul 2024 20:57:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 491186B009A; Mon, 8 Jul 2024 20:57:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 2BC686B0096 for ; Mon, 8 Jul 2024 20:57:56 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5A7681615F8 for ; Tue, 9 Jul 2024 00:57:55 +0000 (UTC) X-FDA: 82318402110.03.7EEDCB4 Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) by imf13.hostedemail.com (Postfix) with ESMTP id 963EC2000C for ; Tue, 9 Jul 2024 00:57:53 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=dvB3HF0Z; spf=pass (imf13.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=nphamcs@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=1720486650; 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=2RndljY+ojuqqLEThPj9Ebbm8sK/uGI5QU2zT6/ks0M=; b=FjPmedjGYKBzXyiuBRYxqghK7QgXtoXXdvcWIFS19eBW2smWgf0u6gpRKfiIKp5A3MPyXU wKDhcz1BoilqO/8EytofYKGMFtpvrn8/P2DRHQ8AJRDr9q4P7ks3wb84NREjvQeXzybx6r VIAxD6YsNnfH5jOYea9cJHtpgguAH+8= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=dvB3HF0Z; spf=pass (imf13.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720486650; a=rsa-sha256; cv=none; b=ftprYwLGYlvox6dUONOrft8RvhA5XbbQdmldHRnpJLNgcT2azT9+xuzj+EVps0o/+TWxjw qpBNWz2kMENL2rSPuvPU36vCa062JyuX9fqzbJzWjp+BNRZGe6fbBU4gcxnCVoMasUoyKJ 6CMHiajiDGIL7rixQf9cfPpytvnxPE4= Received: by mail-yb1-f174.google.com with SMTP id 3f1490d57ef6-e035ecb35ffso4279155276.2 for ; Mon, 08 Jul 2024 17:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720486672; x=1721091472; 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=2RndljY+ojuqqLEThPj9Ebbm8sK/uGI5QU2zT6/ks0M=; b=dvB3HF0Z1pOCua1WgmU8mLiKwLbZS0g8PtBDJMWheCbEAyOIRyK+MPWmzOQWfW+m71 Z4udKThX6uv8g9sg64DsIy0lWGert1J3qMzETM1BoyHQQf4ffkcZd4o3xxz2sF7O7zeE DFQP92yQBCDyxEQ9lmg3WRYUkfngxqiyGLEWGCz+mXphYJkkgz0yx/R9A7XjqJefn/Qw k7hA4uCeqPnf3TI5pkFJ2uPjVbvH/kNeizsrIg24t/UV6UEVEKZpo4mvOcWdrbfOQqG4 +ZhUE/IIrem4jch+xj4Cyf0sXVUM7JYjtzf78HrlTX+qzCmJ3LSeC0lDzlt1KFKSBG7B CVQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720486673; x=1721091473; 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=2RndljY+ojuqqLEThPj9Ebbm8sK/uGI5QU2zT6/ks0M=; b=oK/EA8ttRrLk577r8cP1XL7fnIImGYOOOVVIA8yB1lJvR6NcjbzkTmCcslBzeS4R3Y MgMbrBv1allk7k2xLgcfgCxcrNxEKdg7WqRbmh354IPKPpbhz1RrEd+g/6O90mvK/Bzn QvOC1NbGNPm9w+FwBGMrwls3QopAt0FmxTWGlypWA2rfNX+ZJMV79T5pNxuA11pkxGAK E5Jyp2ijwsi5IJCvlrHNf0DLsqtNpDoxqfbARq9d+6X0mp6HLR8DQVowbPdS71lLijaB o2Kh2c8KPvz7mcWrPU1NpYmR/6Mky0uDYrPcaLVGSlljOKYSG7qXxsy4c/r0aMhz/vLp HBPA== X-Forwarded-Encrypted: i=1; AJvYcCUJtpmfAITrhtbe+19GMxRD2nEZ5FmWi1Mqs/lNETe0lA7dBIUrTQxjDi2q7rxjMIDaoaSxUR0FzJ5lN8ceoUEN+Xc= X-Gm-Message-State: AOJu0Yzii5vW18cKmnMePGnD7oZ2X2xbv2VQR+PuEkRjur+scgtvIOEG e2vQkqKAU0ZtFT8QCF52yI/nN0opDhCIBQsYassJNNUdpwEywhr7TL+o9lRgYMhFzFgVksAQKQL ybZD8p5aMC8j/rpJTeE1blRNd4g8= X-Google-Smtp-Source: AGHT+IFUElNwsuD2/fvQADjVk44tQ79KBYv0RH7VC5FPIfSpUsuA1MqG5hRQv1kgsIWJFnrV2CNyogWNYmSn6rPh5T0= X-Received: by 2002:a25:8243:0:b0:e03:6020:4708 with SMTP id 3f1490d57ef6-e041af3f4d3mr1537658276.0.1720486672584; Mon, 08 Jul 2024 17:57:52 -0700 (PDT) MIME-Version: 1.0 References: <20240706022523.1104080-1-flintglass@gmail.com> <20240706022523.1104080-7-flintglass@gmail.com> In-Reply-To: <20240706022523.1104080-7-flintglass@gmail.com> From: Nhat Pham Date: Mon, 8 Jul 2024 17:57:39 -0700 Message-ID: Subject: Re: [PATCH v2 6/6] mm: zswap: interrupt shrinker writeback while pagein/out IO To: Takero Funaki Cc: Johannes Weiner , Yosry Ahmed , Chengming Zhou , Jonathan Corbet , Andrew Morton , Domenico Cerasuolo , linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: nfy3g4m3z8n7snzpdqs686n15yg3kooo X-Rspam-User: X-Rspamd-Queue-Id: 963EC2000C X-Rspamd-Server: rspam02 X-HE-Tag: 1720486673-70053 X-HE-Meta: U2FsdGVkX185z9r5T1amDjYI+HeonPOQXOhZkMVoOu3JBfA733dENg+MMmNbaFJnDLPHrtYnrAk74OL+WGoz6HS5zv5sAuTW2n8YSV4od+42ewYyHqCryedMsY7JTI1Lzz0JhGU5ql6ZTs610TIsjrCyk8ETrArRArm4z3jmH7gpwCsYKCp6hDmYFTfXC8T+8VbNPUpfp+YGyZGBR/8lPLsd7o3u8XcjezalCgZruaeHaCKutStGGeRvR4SJs2CLnd+NsmWsUtFO3RfuKPxNMvxNxLOIecy//BldXksX3ca1ykFuD+p1noxoWix8PKGiX0xse9RwNtH86BpNOBMO/5m6riBYjW5dcA6fb+UG3JgxXlSh9fbID36vFGKx4rvDBXKU6+HLMvw71I0IV3KV0p2BE+rYFLEzZo2VnL1pZ1z6UcWVWjWtvpJoVMJ1HRKonWv9F5GwJjrkHdhQZV3QLVSCyATqyJw/y2fEpPve1pu/tXyK2Li3EeDGbAeZXRGVXMSbD6rxnzHpq2YjK+yIz/T4cbbMJf+2RhfwV60Deg+aJRa1nugu8JhkC4Gyq0QtrUi595vcrfoVogiXVaQ4+ekx9T+xlLqlD4ol0ZDXfQHnTsWUUdba7iDjoMuYX1vf2xZMSaZI9vNcmHP7XiezeFzg7Zc5f2uBKV59BSMBoYvGFj/GrABdhPlB83MHkd8g0tpm8sTf3Cx/Ym5PEz2q6jITdDyHzRorzIVezudKphu0KiTrvl4pJiXX4U6BdMTwZ6z3NihGA2EVYSaV6cjGXP+6CGrnxA6vx9SAxLBoS60lRQh5QChs1t0qSy0n77nGxyuSS2AkluVP3Est4+l4gTS4wf/IYfGO+vyqdQ8t4Jk4jGZ2L8EsDTZ1Qd6fY50wVtMikbl9GB9MLFaz6NktWDwE4fSRqEm4dIpCcPCUpH7ANDvznW6JGHo3TF1UBy1Rd1JHuUtnc0i7CLb6/xv VsTQV8d0 U3InpiTOlikG+OL2/V2HsQJHn4BpszsXrteU+5Tsa9jlwvWo3wtDrhVd/mQ/kT5tjrsIZhy31xQgY7f8nEewV66hnT/khunJTcVYpzrj0FFZF+O4ens7zcUQfVn1yulfo6dpC8UjrGnBOTGMBqNLtadNRgzsQdWmGs7zYstqxVFf4/bIIFTPgPGQIbMbn3bx+1J5oLgZrLl4Hz9ZH6kV3NUB1TM4gu6lyUTxMoG4KckeSoUX64k/8FEWlr6LgU2sE1FQ1ozyerBm1vhWiRq0bja/E0ieXyoR+TdPN5EEkp07bLtELElnGVRZeCzQx+HgOccAz X-Bogosity: Ham, tests=bogofilter, spamicity=0.000374, 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 Fri, Jul 5, 2024 at 7:25=E2=80=AFPM Takero Funaki = wrote: > > To prevent the zswap global shrinker from writing back pages > simultaneously with IO performed for memory reclaim and faults, delay > the writeback when zswap_store() rejects pages or zswap_load() cannot > find entry in pool. > > When the zswap shrinker is running and zswap rejects an incoming page, > simulatenous zswap writeback and the rejected page lead to IO contention > on swap device. In this case, the writeback of the rejected page must be > higher priority as it is necessary for actual memory reclaim progress. > The zswap global shrinker can run in the background and should not > interfere with memory reclaim. Hmm what about this scenario: when we disable zswap writeback on a cgroup, if zswap_store() fails, we are delaying the global shrinker for no gain essentially. There is no subsequent IO. I don't think we are currently handling this, right? > > The same logic applies to zswap_load(). When zswap cannot find requested > page from pool and read IO is performed, shrinker should be interrupted. > Yet another (less concerning IMHO) scenario is when a cgroup disables zswap by setting zswap.max =3D 0 (for instance, if the sysadmin knows that this cgroup's data are really cold, and/or that the workload is latency-tolerant, and do not want it to take up valuable memory resources of other cgroups). Every time this cgroup reclaims memory, it would disable the global shrinker (including the new proactive behavior) for other cgroup, correct? And, when they do need to swap in, it would further delay the global shrinker. Would this break of isolation be a problem? There are other concerns I raised in the cover letter's response as well - please take a look :)