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 CDFFFC47DB3 for ; Thu, 18 Jan 2024 18:03:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 544066B009E; Thu, 18 Jan 2024 13:03:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CB396B009F; Thu, 18 Jan 2024 13:03:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 31DDE6B00A0; Thu, 18 Jan 2024 13:03:48 -0500 (EST) 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 1952B6B009E for ; Thu, 18 Jan 2024 13:03:48 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C195D80C8E for ; Thu, 18 Jan 2024 18:03:47 +0000 (UTC) X-FDA: 81693204894.29.FA13A03 Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) by imf27.hostedemail.com (Postfix) with ESMTP id DC48C40021 for ; Thu, 18 Jan 2024 18:03:45 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=08feWwAc; spf=pass (imf27.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.51 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705601026; a=rsa-sha256; cv=none; b=Ljl99QN0I7LR0XPVzPMVI1v2eCTJJslpNK8qQtGpneyVP8vMj6gXJN779DaRDW2khJNCn/ hpU4oq3IxsM4piH6ahRyo1q5jXKDtbszpAbMJlAbdiIJxh4cfxbh2ZApPMJQp5OHhWEOZw 6eBGX5b5YEqcv9ZeKQb7QC2lVmTISOU= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=08feWwAc; spf=pass (imf27.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.51 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705601026; 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=u++TN5BQM52YhlIwy5f1ecRhphCfx1QpfCF4yCVI41k=; b=HrrLyRu0U8Cz5USGJHe5ro4mRBwlKPloxviFKswwA6MYlZ6SVE7LBXFhlDs+dBVqfyvKa5 5IiKVEgThFBQl4/Gj2K0AAzNmIoz69MT4m2bqvvOJ0ZKGQSO1Fm9k2TwcmR8rV0smq6RMu lMv4kYAi+6azmDpNuy0R1/bzP5/xz+0= Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-a2d04888d3dso727159666b.2 for ; Thu, 18 Jan 2024 10:03:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705601024; x=1706205824; 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=u++TN5BQM52YhlIwy5f1ecRhphCfx1QpfCF4yCVI41k=; b=08feWwAck5bRLvlA9kEPdGAT5o6DOvf78mDHs9pFmXNax1dNi4jeQDtZruwdxBeLS6 9MsBIMvyhiOJxQUMVLbTM3pU9Erj+zMe2817bKW7K7Vso33KC+Z8Bo7UJ/Dro1spz5fr dE2YlQ1+9nlBlEf2mV0VRvcKgYqMxXmKQvf/ebrJmxBvXdunIRDrSOZWtxR54Qyai00G BvZSGpGjrx+AjeyfzMRrc/9Ze5YaW6bQ1wtXq3XZGoEc4Dcrq157I0vXZU2vGuZeb+QH mc7sBApZnTfee/2rLWwDsxqKU9e2w54YLHE8hEL0nvu19kKnRDBVrWJ0OpTj5pcB6/pM ScaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705601024; x=1706205824; 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=u++TN5BQM52YhlIwy5f1ecRhphCfx1QpfCF4yCVI41k=; b=YPx7quqb8cUPH9yA/lLJhHyf8rCRPjtkCOBGACjXmWBtAuluN2Y6XPu8GszVxjHoQP Bmz5OfhB2Ib4CGisOH6BqQff91dLLcix8SKWERo/SMonTnJUmTt9p29ulVC2TLwIODct Ldge9OIvt7V+jlHkeuIzFgQ4NMiByWwD1znNgB1tfNhUgGykgFJIGNNn4eFWRkYI/z54 WWgEH5NEIaKGVCT8uVvZZx7jRjaZ1HtrdBX2jsH5iKzTtpDT3ofDSHpoOHSU2MWvzn0U 7/YOtaD3KVSwyxJW6UW5X8A5Yd3tTyaz7uqvDLOpv304K+brtYcyTy4u4av9Bc7PaWp+ R+1w== X-Gm-Message-State: AOJu0Yw/ptHnQTaQgO/j6d8f/VoO0UccjKv8TfVSaZBltxqswxjJ1LSR Duxs0UWBFFkAtHXTEMyHKfGC1Y1iVBr/AfCn67qDIoSUxWF9aE79Mo3pY3m3JOSGUqkN7JWy0eR c2+wsWI1W6c2dlALmGfRXz5r3Ct8+46qrqe27NaP3IlldbutQIQ== X-Google-Smtp-Source: AGHT+IFFxNo0QBZ3dkHrHTVeVHtZ+aGP7jjC3zZHGDsLV4nXDLTUNFpcRoU3k/2BzzO32sYG5iTc0+Vw5TQdAXS4448= X-Received: by 2002:a17:907:6d13:b0:a27:f2c8:acd3 with SMTP id sa19-20020a1709076d1300b00a27f2c8acd3mr937430ejc.94.1705601024112; Thu, 18 Jan 2024 10:03:44 -0800 (PST) MIME-Version: 1.0 References: <20240116133145.12454-1-debug.penguin32@gmail.com> <20240118161601.GJ939255@cmpxchg.org> <20240118173927.GL939255@cmpxchg.org> In-Reply-To: <20240118173927.GL939255@cmpxchg.org> From: Yosry Ahmed Date: Thu, 18 Jan 2024 10:03:06 -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" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: DC48C40021 X-Stat-Signature: ih7ukk593ec8uckhmtxnyfu3e51ncu34 X-Rspam-User: X-HE-Tag: 1705601025-725530 X-HE-Meta: U2FsdGVkX18pG8+C7CjLYf9f+vTuEX6XELhDMil8M3K1P6kykOZjD1YtY/LkhRBwBvduChaolb6mj6TOVEHwB1HM0bgxJ57d0tT7TovQLK7QGQeIyZeqx6LWPvOO8bamyG+di5ilCmxThrg3hdPPUFVPGBurYeFdqlEF4ijGcZUXLama31pwaPS2uezdYfALfeCh1KHMC+EMggnF8XpvCGqZMAVFkyhpvaDSKrCBgBD16Tg9ZAN3iLmZeGLQBWQfKB+OPELfKKz81TNcFGAQiFSG9p9x6/V1c1r097LfqND6SNq0ZIqHj7s0r/oU5y5GKDZLp/7RFHskF9ilu718d0PR44jboRyvcmsb4kK0w5++dl0GvRq9pXNjMfgPUYq3c5TBIm2XFM8+xfcWF4Ioh3tJbqgGJuaIA9zFfuePKfuZ95nuBrQevNk66zBUN6kSnIkrx0Q3ab67WAGs53EKEwXDb+NUFRNi0EkbE1YVmuMOq97dipTkGHzWn1PVkdsn3VysThI3nxkQBPo4WtVZtXMh52D1E562dseR4BGGvphKbSgAoKaBAjCKblCY77UJ/wFjN3GGj0t8KtFlupoH+w2jXPWSfrMybDcKefjsrtj6HAonF19fLj8HsJSRrHhSdl9H1x5IrCU7yxy2Q+WXb5o8diVHGnJm/Ff1DRHMxVlMPbdvBDBN8/zpwOv4xIRVyGuft0tcbHfVs8bqhqFhvpu2QUVITp9kjuUhwPJpAKBVhlhUh1AfRaUHIpsqidzuc1TVh1S4HZhrgFn/RzMpvGEDoKiZbBbCZX2f6Z2i8rWZnbxd0cTNUk4CzJOtcZFvIBdVMe26da1CwsXPjhJ+O2Hv07F5EfI0GAxLTFGtEEyctzVQNvjvHndpnlN2C6up6JtQ0G4ogd8rn1/gGTMAG3YFH/v8zrPwW++egI1xGQMV9po97Yy/EkPKn7jVUZsz5/3NnciMOeLPmSlfJFP y233hCML 3YAV9n0e8+3C4floIwqS9+zO79T+/WuOtZ9NrBTB39GzyHtMR9u3qx446e9ZsSdKerFvP4bZ61P5AoD44uF1gpVfG6Yg13X3hfmGfqgSsViNhT8frGGU6Vw3JTl0zCVukkgA43VuDB4frI+fppmT4RcQngroVk9kf//3dTylj4lbDQjqbEsoUBiqRzLTn2yjljPHIpwo+9kw65pO4YcHAxn3fmKVTXY7HEn2YSysyUPBlG6rPTnpkIRwWbELzcbgmM5KAhcatUjZ6HpXUJRhOflFVriY0LUsBMVdblzW7C6Unydh8coPT3qNjaEog3BVNMXLQ2muEkRVsOj0mLEDENlHMzB3ar0e+ZK39FSrNUW28uM4dI9j3nMOS8URFL3IeDuu2eG8eguS8hDZ/Ov9e6XBpn9cAdgVdgQCJgUeTYm5xXntENZAzhOj69g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001936, 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 Thu, Jan 18, 2024 at 9:39=E2=80=AFAM Johannes Weiner wrote: > > On Thu, Jan 18, 2024 at 09:06:43AM -0800, Yosry Ahmed wrote: > > > > > On a different note, I wonder if it would help to perform synchro= nous > > > > > reclaim here instead. With our current design, the zswap store fa= ilure > > > > > (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 agai= n > > > > (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 w= e > > > hit 100%. Just enough to make room for the store. This is important t= o > > > 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? > > I kind of am. It's worth looking at the history of this knob. > > It was added in 2020 by 45190f01dd402112d3d22c0ddc4152994f9e1e55, and > from the changelogs and the code in this patch I do not understand how > this was supposed to work. > > It also *didn't* work for very basic real world applications. See > Domenico's follow-up (e0228d590beb0d0af345c58a282f01afac5c57f3), which > effectively reverted it to get halfway reasonable behavior. > > If there are no good usecases for this knob, then I think it makes > sense to phase it out again. I am always nervous about removing/altering user visible knobs, but if you think it's fine then I am all for it. I think it makes more sense to start writeback early to avoid the whole situation if possible, and synchronously reclaim a little bit if we hit 100%. I think the proactive writeback should reduce the amount of synchronous IO we need to do in reclaim as well, so we may see some latency improvements.