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 8D4A9C47DAF for ; Thu, 18 Jan 2024 17:07:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0630C6B0080; Thu, 18 Jan 2024 12:07:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 012E96B0081; Thu, 18 Jan 2024 12:07:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E1C036B0082; Thu, 18 Jan 2024 12:07:22 -0500 (EST) 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 D09E36B0080 for ; Thu, 18 Jan 2024 12:07:22 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 83A9A1C16FE for ; Thu, 18 Jan 2024 17:07:22 +0000 (UTC) X-FDA: 81693062724.11.C4F4F3D Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf22.hostedemail.com (Postfix) with ESMTP id BE759C0016 for ; Thu, 18 Jan 2024 17:07:20 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pYkXBuSq; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705597640; 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=HlYwd4ZgoThSOWDK/BI/ByWriREGCZu6HCgLz+Vx7lU=; b=NFC8gt+IghNOdk3G78RsOcjwfFwU+eyosOAV3eb1kyc/ryCW1X14fTgg94mx4wzNkMhSou PS86JTwV79PTS9M1LHE1bhk6SV+wsOnEkjRoS+RknAazTnIAvS1MVCFZk0L7zNGSLsOR9P BsP2udPx8y4h/QGxqEg4xJCubElescc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pYkXBuSq; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705597640; a=rsa-sha256; cv=none; b=PuPhW2u2ekHOSFpxYScYJF34z+w59I/iW3oEixCBPX3JvkODL/dCLPsMMYViPUas30XCPT NdYJroWNgdWnJThcAxymo+eki9syNjm/HJv7sqByP1lUfHHGOCw7MqJpXEBG6hotX4ocCu WnYWHA9eS6DAHHf72bJTHNwx0oQm0bI= Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a28bd9ca247so1496481566b.1 for ; Thu, 18 Jan 2024 09:07:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705597639; x=1706202439; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HlYwd4ZgoThSOWDK/BI/ByWriREGCZu6HCgLz+Vx7lU=; b=pYkXBuSq32RO9WUk0TuE75N2y+vlfrbY50rH/J93vj8+XoeudLjhZ8JrhC/6bktgIE nhDmJsUrTAHDsuQKdvh2UI+s4xGzx0Iz5tiVGer1uOCLB8VLq1sl64+32vaCd1dM34ic SlWcanDo+qT0Cwhi2Hdc2Qwc8FcmHhigWxpyU4FMrxRqGySGLr8bjKJRzlaTJKCXZhsF 2OvcHRoVeSJRDMdGGSiDyX3tjvTaW2RNWQruqxVnhd8KVJg7UBMxk1GvR3LkNiJEXLTa iOvGWOWn32Hqv1MLVQL37oScDbAXL7UznaFWvQnEjQCOvR2BBqp2dURK3xDqQ5OVvHtJ 3NqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705597639; x=1706202439; h=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=HlYwd4ZgoThSOWDK/BI/ByWriREGCZu6HCgLz+Vx7lU=; b=AXEv71MaXalqebHMu33ULeuAtsVGjKHFjifX2hNxNJ87d0hC3lHfngZJMM+q19zFUN t4i3KSLy9o9ihQ9VzUu8T7O+ANZVImLfXdWq5DnqdEYzM5t6/4HLcnZatOmfYSbLGw1Z vzRhW+eN3f4zgBzA83PWeLS23rnSpzXOB/m/imRWH4XD6U2G2HkJ2NMNzb8eyD1FaYGc /j4+9su7mropKd67bIYHwLVEztm6Wx/XmA/ejmFn10weCoTQ7ogNK1bmlVP0JcKeEydE fz2+2BwShWR57cnE8G54IxI4IL/hlkbVvozcFTmVKd+qAnZmq8gflW3fs+Vc/udqcd+R ZOtw== X-Gm-Message-State: AOJu0Yy4cnRA85XiYu/AyxHMjvBloCHuqBG0yj2ZOzQLYi3PS1ek+PSE 9hNA2TpXoGghQVNdBQKids41fsc4Sj6kW8UsdEPBrEG7GnkLZfcr1R8aof7xh36yaKA+mBfxlwV yD0PTUOM3AlEDqv2ff4oetrvzosQjMxOVPiPg3NQtYsncImcPpg== X-Google-Smtp-Source: AGHT+IH8tvSJMBVtMjgt9oPnZXK6j/SOiKaEy5MCl32mJd7TLLo+oh5V3GfqfLmK0RNVJ0qI/u/fj1frwUcpuq7wqzA= X-Received: by 2002:a17:906:eb4a:b0:a29:8155:b813 with SMTP id mc10-20020a170906eb4a00b00a298155b813mr781055ejb.85.1705597639224; Thu, 18 Jan 2024 09:07:19 -0800 (PST) MIME-Version: 1.0 References: <20240116133145.12454-1-debug.penguin32@gmail.com> <20240118161601.GJ939255@cmpxchg.org> In-Reply-To: <20240118161601.GJ939255@cmpxchg.org> From: Yosry Ahmed Date: Thu, 18 Jan 2024 09:06:43 -0800 Message-ID: Subject: Re: [PATCH] mm/zswap: Improve with alloc_workqueue() call To: Johannes Weiner Cc: Nhat Pham , Ronald Monthero , sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, akpm@linux-foundation.org, chrisl@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Stat-Signature: 3z53ta8cb45f9wau86xna9iqxqeca19h X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BE759C0016 X-HE-Tag: 1705597640-734724 X-HE-Meta: U2FsdGVkX1/ssq0p6s2Fpo9m/E+aSWMkR62QsWJdvvsBhg0ZB7ZTYWUXmNRMXU1GMs1FaFNe4hLhkcEI/Iqcun/AM3HC/lP7VioSmn9UAQGacznL82f/zNPvm64FFF7NBw/cqdwwIYiEpKGDFLvbBHeqcIwocJ9NX5nkMzBCsztBY5swlGO5tsn+Uz04sscBgv/tniJw8Vfv0uBZtrHIcPqOaAIp1kWn4cgev4DRvHLG/ODDi+cU1JR0D6pS+Ue5ibHsC06GTmP761G8am5K4PT2onf/j+3PxE5/xpGKnrHqQmhdsEdn3s7wLSTwT1Pn27nfh1SNi5KvCDD3+qmbozD/5qPkwdCFTKHOzAmmL17f6oPaSC2DIF2R8h+hcCUU3esZn5N0MdUe1CqwFvVMKwjCQtle+adRcXNSs26mQvNHsRbOyJrDWlsM5KWtp00AixMVHBn34ZnZPs4SMP6uv8pxNy0s+wKTdJ2leulv9cs+heCOFjSiCamZ8C8YOzcqcJV42vOmDuocItkcmawjVSGOnOfo+/RkC2Tu/9dQhrxxfk/5dPT95uMJ4q5FG0UFNFKVEkpNKC9+DkHTMGpV70kbp7kC7JKCu1W1o6RYXXA61eiQIBRXtTGRlRp54HE1x56kqV4ikrTnNGcFHHboehpVODMgvHrussILABRJ5dkR4xvZgisKTmuHZwTPMmYM+9ZC9QdGmADuBFmA04+p4ouHcCqRrnn9Y9PII3vooXktFJV61Ud5BBMpCTldHfnqxBpdVIioxXKxxbr22qkI8UUsYl3E1uDp1evXE5tST+h8qTUYE4fYeQqeyUD2ssg4YU23EWSXDWQWbLzRe52nTYAq1A0KuxYXgeHUJC+owB+WGAiG8MsaxwcYfeRUtbwbT9cYdz1TS1I3NyYYOgYeb9HXFdRwp84h14csV1u2Itf4nHNj51YKQju8reWpAwaOpCQtwKlSEtbICAtfKRy 96CQddrk HaBVaH2u6aHxRw9BBoKGzoHSCvSoaOGRi6zkRPie61+VLogEjkuqU43CxrDrQIcs2ft6T4Me+dQtNlvxzimuUL5m5kIfHTDdD0gCy1MUKmPoIcx7Xh1yUjz2cDAFFbnrW7ojmANktV3/SvgN8eDfm7luU2sGuDWpJl6Zfy7fzoplIL9UgwlHZYejdBOiCqbH2BPT8x/0JmhvDEm3woptv2cFU0LEY+X9GGj5pCaS3FsZdIUsCo97QJ8/XvL1ntWeiBUikn6XMZkfwWKCby52GeuvoxzqhLL0y2SAa9UUGJqhlDBu4clpXyIQPxBQuBpAinV9iykzniOdx9nn6Vo/y5LdapA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001653, 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 a different note, I wonder if it would help to perform synchronous > > > reclaim here instead. With our current design, the zswap store failure > > > (due to global limit hit) would leave the incoming page going to swap > > > instead, creating an LRU inversion. Not sure if that's ideal. > > > > The global shrink path keeps reclaiming until zswap can accept again > > (by default, that means reclaiming 10% of the total limit). I think > > this is too expensive to be done synchronously. > > That thresholding code is a bit weird right now. > > It wakes the shrinker and rejects at the same time. We're guaranteed > to see rejections, even if the shrinker has no trouble flushing some > entries a split second later. > > It would make more sense to wake the shrinker at e.g. 95% full and > have it run until 90%. > > But with that in place we also *should* do synchronous reclaim once we > hit 100%. Just enough to make room for the store. This is important to > catch the case where reclaim rate exceeds swapout rate. Rejecting and > going to swap means the reclaimer will be throttled down to IO rate > anyway, and the app latency isn't any worse. But this way we keep the > pipeline alive, and keep swapping out the oldest zswap entries, > instead of rejecting and swapping what would be the hottest ones. I fully agree with the thresholding code being weird, and with waking up the shrinker before the pool is full. What I don't understand is how we can do synchronous reclaim when we hit 100% and still respect the acceptance threshold :/ Are you proposing we change the semantics of the acceptance threshold to begin with?