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 04004C48260 for ; Fri, 16 Feb 2024 05:09:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C9C16B009C; Fri, 16 Feb 2024 00:09:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4504E6B009D; Fri, 16 Feb 2024 00:09:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F1696B009E; Fri, 16 Feb 2024 00:09:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1968E6B009C for ; Fri, 16 Feb 2024 00:09:55 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9EEEB47983 for ; Fri, 16 Feb 2024 04:16:35 +0000 (UTC) X-FDA: 81796355592.23.74DB1AB Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf29.hostedemail.com (Postfix) with ESMTP id 97D6E120023 for ; Fri, 16 Feb 2024 04:16:33 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="JMf7oFB/"; dmarc=none; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708056994; a=rsa-sha256; cv=none; b=0XplHKsU4eCutgv8bN2yCKiiac0Mf0th4CAIy0+AFr2MFOuy9K21iaxHZXBSUo76IAFSaB wXvrox2/0zUaNEOBowaHoMD7KqAPMfcZivuJYy5ihsvOdD+mKMaTR4aObz8En+7DbvtFwY 7kTvJZo6haLTqb5wl7bGDUuRX1iwSpM= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="JMf7oFB/"; dmarc=none; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708056994; 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=CV2CqnlCZdxTYGjAa8ndSv3N6EPoWIxxTs11iVbJlGg=; b=xXJw4TNpp7YWcI6LxILScXYUow0pT1XBOyaG7TOwgyRALN6erOPD2TEUOMADynJlfa5HE6 tbTdThe0gdpHKHYYoydh3soxCbxppjvI6jC9xBfIlGHIQS9ve+UkljPBtO9IqP6rMCUjNX 1thFoNwLQvpcYjxkjOzqKiJtAjzym9s= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id E1574CE23F8; Fri, 16 Feb 2024 04:16:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2EA5C433F1; Fri, 16 Feb 2024 04:16:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1708056988; bh=sUxXigIboc9iP68W8TP9S/5UxJ1R1MlA21rkHc06KEQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JMf7oFB/ecGdP2c3QkPhYjjbePLbikrAt7dmWv8nrdDMNsNFliGc9DEjRK57jB38B 68YjhDSAUnWKltkJC42+AlGd7wJp6GL21Uiqh0ZYDWJG04sm6wS1WkrEqQBEbWXnQF 11GlZf75R65UA9wZGC0DHB7ZjbQKDqkAjfHESTw0= Date: Thu, 15 Feb 2024 20:16:27 -0800 From: Andrew Morton To: Tim Chen Cc: Chris Li , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Wei Xu , Yu Zhao , Greg Thelen , Chun-Tse Shao , Yosry Ahmed , Michal Hocko , Mel Gorman , Huang Ying , Nhat Pham , Kairui Song , Barry Song Subject: Re: [PATCH v4] mm: swap: async free swap slot cache entries Message-Id: <20240215201627.5abd1841192feaa262d545ba@linux-foundation.org> In-Reply-To: <1b9a69d1ecaac45a228eb2993d5d9b8234a84155.camel@linux.intel.com> References: <20240214-async-free-v4-1-6abe0d59f85f@kernel.org> <20240215161114.6bd444ed839f778eefdf6e0a@linux-foundation.org> <1b9a69d1ecaac45a228eb2993d5d9b8234a84155.camel@linux.intel.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 97D6E120023 X-Stat-Signature: 16ezdss3wdrg9rkjmiwq3hgxz5ax81p4 X-HE-Tag: 1708056993-331350 X-HE-Meta: U2FsdGVkX1825QnOjMYuCnDQguOcOfrBzLNF93uRB3VFMbHkmtCAViyUk3ifo0FwzaozUgGkNcsnhK1Ttr4iffLtJ3oFugAeCi+s9B5aTqBKNoSfQZP62XPtdvbRUk4zpj+JImS+x1YZKdKK4yVzyTlyZX4WXE6iZYqvqPoBs29ZmZsp5qZj/iLHpSUGXkmaqjVXgPgZA7ebqV6gruoYHTuxlqDvIZC26t5JF8nmgo+ZbR5KJrLvWv4z+zUdcbanVdItEzRf08lxz9H7yvSWWnUCBQFQcmNqxNmjUC6aqmC9+lR/bEZbZNbcMjZQTm/E9P55h2whxC7B4Bv1FAhbR30K4Eic1D6XED1c5FWvL4/UAO3otDmbpRwFV/1lOccqQaXXrsJ/8zNQ3Td5fUIIVZ2ex2LQw/dbtkGZUIUnWDQgcIBIBtCJwmN1qv8Wz0a/u+JyVwiGyTOsTtmM/xyNBXMVVYK5+kdJsDK54MotnLL71wuvcJeXdhTwPg0hmZPQVAQQHDlB9sBHUIavGB+ORw7FPXJJRk03Oh8CYtEn4Hc7qxrOPxOZCVhB237FkFU9sFD3vEeimT2HvdVozhMoJF72KCyLtmQJpWbWf3QEg8W71+dlb+RnCQIzVGdkrs0ANp+t6dJSutOcaIVB035uV1CZ8vhAOVt14lFhAEngc35pp1/RFjr6R0s3HYlE4sbKfDVBh8Mo/sm1kbt8Vxf12hPriw/P5Qw2w+WwNBRJXtIhcUm4vPSdNFxq/vJ2GwtPuLA5uvmaHux8z0G6J6upMoRVoAKS5PKe3p2kq2CpTiPjPkOhEaCb/UbbNlr7OemWB+Y9Zc4tltFWU+K47uZcL0JpMM+/Yg3dC0I5qFPd0JEtXc868jXUhXPI6UI5/vk69FTJWrDoZSDnL+4oHJU8q+EqRZ7C0qv9k3AtIEzwzNRGiuYwcHYfIA== 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 Thu, 15 Feb 2024 17:38:38 -0800 Tim Chen wr= ote: > > What this description lacks is any description of why anyone cares.=20 > >=20 > > The patch clearly decreases overall throughput (speed-vs-latency is a > > common tradeoff). This, please. > > And the "we don't know how to fix this properly so punt it into a > > kernel thread" approach remains lame. For example, the risk that the > > now-liberated allocator can outpace the async freeing, resulting in > > unlimited object windup. >=20 >=20 > Andrew, >=20 > What you are saying about outpacing asyn free is true for v1 and v2 versi= ons of the patch. >=20 > But in this latest version, if another reclaim comes in before the async = free has kicked in, > we would be freeing the whole cache directly, same as original code, with= out waiting > for the async free. It is different from the first version > where you go into the free one at a time mode while waiting for the async= free.=A0 > That was also my objection to the first two versions as you could be in t= his > slow free one at a time mode for a long time. >=20 > So now we should not have unlimited object windup. And we would be doing= free > in batch of 64, either still in the direct path or in the async path. >=20 OK, thanks, I didn't read closely enough, > If the next swap fault comes in very fast, before the async > free gets a chance to run. It will directly free all the swap > cache in the swap fault the same way as previously. And might it be a win to cancel the async_work in this case? Again, without a clear description of the userspace-visible effects of this problem I am groping in the dark. My hands blindly landed upon the question: the overall effect here is to leave worst-case latency unaltered, but to decrease average latency. Does this satisfy the yet-to-be-described requirements? Also, the V4 patch's quoted quantitative testing results are pasted from the V2 patch's. V2 was a fundamentally different implementation.=20 I think it is fair to say that V4 is "untested", with regard to satisfying its runtime objectives.