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 4C94DC47DB3 for ; Thu, 18 Jan 2024 17:39:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DEB1B6B0092; Thu, 18 Jan 2024 12:39:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D74926B0093; Thu, 18 Jan 2024 12:39:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C16566B0095; Thu, 18 Jan 2024 12:39:43 -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 AACA16B0092 for ; Thu, 18 Jan 2024 12:39:43 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3A2321A0D3D for ; Thu, 18 Jan 2024 17:39:43 +0000 (UTC) X-FDA: 81693144246.25.3A83953 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf02.hostedemail.com (Postfix) with ESMTP id 1190280004 for ; Thu, 18 Jan 2024 17:39:40 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=bNZaxnK0; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf02.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.171 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705599581; 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=Uvq0mFjEzgAFfzxKF8Z+G+SXAKzYV+yY1dbbQe58I6s=; b=D6ke9YBh9H2KS8fcW+p0HF8YDnNKsH3PUmpOE7mu/JaNV5nKF1HL/PXIBBrcxnCjAUo//D fwK0lQGWz/yu2oLxvF+fckzx5M8/YEpr9eX6/w81OjjcgRtfuc8dIDOycISYr1aOcFWqVa 8AAo8GObQzrYmNCfPjjRNzwn+M+Mtmc= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=bNZaxnK0; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf02.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.171 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705599581; a=rsa-sha256; cv=none; b=ewd0ZoNk1bsPLmeXhg3IKEFnZU4fTImGvREfqFBpNvGmqsTKCsufxU1eXgG2RndVsDsMEd o4m+5XcZrgdncGppSgFtWLjWmKWmqxWDi8ABhYMRncdbN1v/n55/NMscEHXZ/J0ay/HQGd 8OUOhKksSjY9jClPKtokqnaeZIh2Og0= Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-429f53f0b0bso20867311cf.2 for ; Thu, 18 Jan 2024 09:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1705599580; x=1706204380; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Uvq0mFjEzgAFfzxKF8Z+G+SXAKzYV+yY1dbbQe58I6s=; b=bNZaxnK0ew2H2CffP2VsAl2fToJkBFP/pawn6RSTrfsgS6jVL3r/IELl+UMmLt4L3R GWMCTeWSOnDxk7AttzZpgDmHTdEvyyo3aDGURMmFFotWTt/CH4Hi4abEf5weBSeBQ5kt CiDMMLZ/zA/25c+vpSnxK5sXri7pnoa3CHKgIox7KolcRtTYvhdJNXQVmWWawtycSdpq QvZAe4buTWTxeeH4SsutuII05BU//6XI/bFpBSN9ZXAKo+H8ElVv0w5f/6vsVLNx4AZg 9Qzt26HJJP9HJApgfI9lnObFW96BcK5YhlIj2FKRpGab62KPkJ8RXlfCygvb2mP95CRr tNSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705599580; x=1706204380; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Uvq0mFjEzgAFfzxKF8Z+G+SXAKzYV+yY1dbbQe58I6s=; b=EnKEBRLXzRvzaxYATX9mZWbasp6NdJx3hAGMsNYQnvpDm5JkxTZcYLuniRLs0UKzkj 6R5gu8vm7UdfN2w3wIWfUqDGDjdz1VDpmqHN7Y0zJDiVL6272IAaYuvLcNeiz92YJI6D KKzAdQQnalJ05QCHXd5KTeHUZxGoJXk3tNTMNuFF9XNrZ08DlVed9mfh9uw04YCsmeB9 kx+g2OTFE48tfQW09oJMb3RF/tJHH8xoWclFtWiOFCIQuuxK7CC6dOUV5MbzXS9GgISX 2pDHOfE7kP/4nyOWMdCL66Wer1sayirDmsv+mEi8JyELuy2UG0Y2SAf2Ea0A7vZ3V6Fo YnBw== X-Gm-Message-State: AOJu0YwJo8zRXvmxHX4e8dZODlljNNHeg6V47gaZGO7PsUj/MUprpDxe 1BwoocpQw8nVAQW2tR4l0F4VKcDBPePTr8hZRs0JvjgTi1BJboelxHdm0dyAagY= X-Google-Smtp-Source: AGHT+IGspJSI/C69p7u1x0P0yeqzHz6GoQcIQ+/Ac9KGCXOZYgh660IbmTXvzXJ4S3SKmSxi0Vs6rw== X-Received: by 2002:a05:622a:3cf:b0:429:b273:22cb with SMTP id k15-20020a05622a03cf00b00429b27322cbmr1178392qtx.60.1705599580109; Thu, 18 Jan 2024 09:39:40 -0800 (PST) Received: from localhost ([2620:10d:c091:400::5:1096]) by smtp.gmail.com with ESMTPSA id bx3-20020a05622a090300b004299d262017sm6903232qtb.66.2024.01.18.09.39.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jan 2024 09:39:39 -0800 (PST) Date: Thu, 18 Jan 2024 12:39:27 -0500 From: Johannes Weiner To: Yosry Ahmed 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 Subject: Re: [PATCH] mm/zswap: Improve with alloc_workqueue() call Message-ID: <20240118173927.GL939255@cmpxchg.org> References: <20240116133145.12454-1-debug.penguin32@gmail.com> <20240118161601.GJ939255@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 1190280004 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: ndegkiqziagfp9r3mjix51wj75oqb1bw X-HE-Tag: 1705599580-997424 X-HE-Meta: U2FsdGVkX1/Y4SjacEH61IEb5dEn433+7OhqFVRXfA9WwnR6KnS2uwPjY1PCK1Hu52pOJ72iN3b/bj7trsUqGsB1PpLzJFxzcsgKdmjJV8DM8Lu7tj4ceX93ZicNspnvGpR9vZG297y1BmSiP/2JiUoT7x35GuTLV6ooWItNihvQzEtgMXMd6Zc3CFTBuCQJ7HoeNDfZWD1GJsnWvraY0WYf4zIh23P+5f/xPf2zxRtegz+K8Li6sKcOr23djUOsoCzYsigyxsc4sWJ1S2ZWElYCa3jnNHqDdmJvUaVZSc/jipQDJZDV+D/rzO7rTCbFeXPMjk/8aGvHWbozqJ4UwzoU5FpARdTo4tVC+ozlcjMWbHiyHsSi7V/wZR1rfsQhmMdbPpxIkj1aWjXh98S3FM7jxaDVKTBJuPfx/EH8SSeXRg5ZuJYJ+AkkhK8fmFOhIH4qaYn4tyNUOW7kNskfiLSdtwBW5sH2asOrG+E2l4vsl7Mt1O9TKTS/C0Bq8RMCc0ilTDLhLsaTzsgoxKleAa0J0xV3xnoPW5aafRRrA5RlLL8Rk7rhajKhpOq3YasWpS9xJL8jAkIYpF4DTqImo1UtN8RTdX2xzwvRDA02+97DBsUwMfQbflWQys28LWACUC6Dxq1U/X5usWs2VDM2Rabajklgmn09CIDWUwDTg/ukbqj/av0qpEF7KKvs/6WzdjOX1RYkoj/jmqm8xE6jM+UcNrNnLGlUn4eQEQbZS6LdW6Hcz6yI4mGbchU1wYA6tcfGyH/E7h2t8J0EGSDfb3rHPixKvpfrZW1Z9Bhh9Qic9ih4D8fH3x2G0cEuZNxFqb5aKP/jx1RvVxlIOsbIZwXO8tLXfI6xOW5cOJRDB/2YQSMaRJzCPa9wws8VxG1dk11XJmHLAIuCySevSF2IC9MdI0l+DuNNuQDIGG9AFrFqV9ioAbkR+m6TjFXAwn3TLwmyKpGvH9DyGhymhmZ sfh4otXx JtFRgLIJv+Z2R3/qppbhND9RwgmDYcXBfDfil6O7+CG7vE33Gp4F1K0POks495mFtjh8wd6Ev15abdFTZhvPdijxE1ZI5DzLPVMVwF5mRq+D80vdCRGH+4Rg8O89lRkEbffvQ0Tvoegg5iYxYskYhQ4M7EXa0wecWGeBoQUZG4/rTy8U/RpZsxi6nxftZEtYDv/R3fV4MgfSKdCRm6pSd7VPEBLG8BkDel6BNwDSbduUaOIKc+1GYNRyAFIY7Vt0TijD5MdPneG45bAX3UESXIPsyCSROZ9fhrJo66Dk4k0DBF+wRS+TX2hatIXmHjC90o4d8IOiHHENMfR16gLX1SQ2idaqn2e+O+2HSeRfXB/jHzllUBAiILPb/jDMIBQm6Dmdg+Js5yPln8hjVAntvPn+jMma9hHqMiL52j8qgKUY4fLx/Ba9di+OvqApP6Wz+60RdfP0YZJ2ExPBDxD2qM0zGlu17U9iSGGDsxluAqb2K7hmWOiFzRRTvcEB7BlhROgYZrXjTak/3TnhI5Orl0AEAzAamkerVY7Lw X-Bogosity: Ham, tests=bogofilter, spamicity=0.000036, 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 09:06:43AM -0800, Yosry Ahmed wrote: > > > > 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? 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.