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 2C00CC3DA4A for ; Mon, 5 Aug 2024 07:55:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B10416B007B; Mon, 5 Aug 2024 03:55:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC0246B0082; Mon, 5 Aug 2024 03:55:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 987536B0085; Mon, 5 Aug 2024 03:55:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7A5AA6B007B for ; Mon, 5 Aug 2024 03:55:37 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C77681A0168 for ; Mon, 5 Aug 2024 07:55:36 +0000 (UTC) X-FDA: 82417432272.22.3226ABF Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by imf03.hostedemail.com (Postfix) with ESMTP id CF94720026 for ; Mon, 5 Aug 2024 07:55:34 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="h46/3bPt"; spf=pass (imf03.hostedemail.com: domain of seakeel@gmail.com designates 209.85.215.182 as permitted sender) smtp.mailfrom=seakeel@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=1722844473; 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=INBENEtf4sdxfdchPv/wrRAKQhXwHBlUGH6Myn4Hj0U=; b=pdbeKZxups+P+O85NWwGGdFCZKSMM7SmhB6ZAbp7lOvt/oPSzYXrNpRttB7zapoBhDIWs7 Hz7StxLWyIagYqgkyVLzvv6/qx7rh1RpW/MH9q7F7i97q0qPTXsQ1whlOn6FCOxn+UnXgZ n+h38378u+UcUaRg1aQQ8+mqsKa7eaI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722844473; a=rsa-sha256; cv=none; b=0Vg/WpNM4h7v1Uu+yv1aviKern0yEMyjxWL/WInshARUP8NVcNkuNvVTh3rfAI1G2ipHMe zv7YJYy+0wDGmWQYOhSde0CgT/CAyq8qaqAqkifPxfrIPrPtg50CEyd2lywshIupGsSome yUPHAwEear/WTuAP1sTWwlGUXBgZHQs= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="h46/3bPt"; spf=pass (imf03.hostedemail.com: domain of seakeel@gmail.com designates 209.85.215.182 as permitted sender) smtp.mailfrom=seakeel@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-6c5bcb8e8edso7616265a12.2 for ; Mon, 05 Aug 2024 00:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722844533; x=1723449333; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=INBENEtf4sdxfdchPv/wrRAKQhXwHBlUGH6Myn4Hj0U=; b=h46/3bPtzH+E7J73yez9DAb3lGcztIeoXHOOgvGHfbVOaRBuVApO7FnDIOrMY9PaVy nHtkU/TFM9pnSWNcTnX5A9b2NVi+IBdyO41k+WX7J4XX5269PFJdeKeKDtNfbRrkoB2F s2NtlipTgnSnhgwdXBY71AfVwu91hrsnmNiYMNuxluZHnRWSkmMQeH7LOYtIi3QqKQly T0i64Ke1HxFATQlwws2lRAcK/nJ72eiqaJqWnkFj6EiIJOcGPLWokznPoCqKTPyM8jjv J+DITsE5cTY+XWp9Tbbn9uJa4rOIZsSXkryXGkdCy75TBsfmXBQQux/yRmiS49rKF+g8 LgXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722844533; x=1723449333; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=INBENEtf4sdxfdchPv/wrRAKQhXwHBlUGH6Myn4Hj0U=; b=LJVCB7drwJXdT7KRRRuNyic0OLGikukSO6YgI1NPDYc9+ZWA+bz8Ysr6uBnaZ4td3k AgZMJMVVRz5BPDmw/gx0Nrt3xsvKtwq7oqCG7Nq8WhZQLhC7+yLtTqEg4/1RVSTqe8lQ jLk9pp2JmikmWuhu+8f4nYSQhZuKEZBqkHi14cA/PubzXzsgN+7E9XwTAbNSqrN9nriq H/2MVqpzBLpgxyEwUo1F6c59/m3vBCgbAHn+r8IzAe15xARRVilhDwb0X8T60mG7l0Rz SML5r2Lc7dKt/vWbz4g61nrmfCFEJEFLuOPkCE0WD7mRt6KUxYew8f8OBk/qEucsUPFy cIAw== X-Forwarded-Encrypted: i=1; AJvYcCWhbXWe7OmWyq1wbNqMbZpAaLzmq2GQUOO5lHuGo9FlBvRF1gHotXM2FhwA3mUhZPlJmN/HtMeLjIMr1C0nAo5zk2s= X-Gm-Message-State: AOJu0YxDwOZvCYQKRj62XfcV5zjfDCyusomBm1nnAPYdbY8eKqYZONZY s0+RbGgX0ENP7+MJgy1xz3MDhfkRXROHm3XdC00KxR/oGKvPbCLOp9F8lUj8l8E= X-Google-Smtp-Source: AGHT+IEm3Rcm4osaFEAsMYUwXciCtGrImm7N8IUC8MOcp58RnKdugY0jprOQ2qWR6+LenWmhOhIIyA== X-Received: by 2002:a05:6a21:7881:b0:1c4:a5fe:321b with SMTP id adf61e73a8af0-1c6995820ccmr16935214637.18.1722844533220; Mon, 05 Aug 2024 00:55:33 -0700 (PDT) Received: from [192.168.255.10] ([43.132.141.20]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1ff58f59c51sm61401375ad.67.2024.08.05.00.55.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Aug 2024 00:55:32 -0700 (PDT) Message-ID: Date: Mon, 5 Aug 2024 15:55:28 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 02/22] mm/zsmalloc: use zpdesc in trylock_zspage/lock_zspage To: Vishal Moola , alexs@kernel.org Cc: Vitaly Wool , Miaohe Lin , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, minchan@kernel.org, willy@infradead.org, senozhatsky@chromium.org, david@redhat.com, 42.hyeyoo@gmail.com, Yosry Ahmed , nphamcs@gmail.com References: <20240729112534.3416707-1-alexs@kernel.org> <20240729112534.3416707-3-alexs@kernel.org> <66ad2d2d.170a0220.668d3.6c80@mx.google.com> Content-Language: en-US From: Alex Shi In-Reply-To: <66ad2d2d.170a0220.668d3.6c80@mx.google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: CF94720026 X-Stat-Signature: uzc1h7t3kc6ga353qydsj7gxogqtka3e X-HE-Tag: 1722844534-270406 X-HE-Meta: U2FsdGVkX19Q/Vef/RakA+mWiDASp0TksMJXFFZDt5E3RbT/sa62ePODBOroJ9SrMDPBAlmRvvBW92Erb47HBiiTChK0Pb0Lvlq20i7KuKX76mGjLIroe1vjpen1KhDf2VYP4ndrLnMX8BTge2IHZMvujtn5lP+lffxZB1W/Pm65xH5HFZdqlcBLkH9FKdgJA85WomEpc9toPKAkVd7qYsNbBr5GPSeTeDnH4jP1iHVWnhGmP66+MylK3qUV4dRfkYOym7fIoIsFRmYgNhDwwrRoN3K5liy2j+dfjYOfHab0ksEu8whCCYrX+sgvwvB9NoLGjD7UN4EwSwK4y0MtZ/4Vo+P27B90wK3ZbKntxzY6vdpNgVILXpfvAi8qXeaUESCs25nBgTu8BM/m8HdSRHHu8islQtwM3Ky9I/pqXy1isvA8gyPuKztvT+ms6evAeXVnLTRkR8HKZnus38V7AhRXLBzg9fldANnvIRbueqJwsltDz5Vi14mboW+KL9b+YxlhY6+97LHGMw3DzoYOz7qCzIKtBK6XvqcC4rmHncKzoHChHxiMtr9wUFfHH2FZdrzO97I3a4gYNTVgIHrQGzw0RqQBP+KfiUc2dZXCpuIU3tZaaFhgBhPXn+FWii1Uae79yJ6ILQALl/vArtb6DpHCEj7Bwh4ByOowNaPcc3pyGkT1j3u/K+CcSsn/VfE4iB88WXbrj9vhMF6628IQpExbL1L/QT6v0FNbxI1qXAd2tBbXQ2ggSKnMdOXHyG6MBww2s5DJsE2cPGfqh/UBy8oYmG28EAceVGfV39yhxHmbXw3PWld6+WFWOD6REduozsb0tb9wJd8skZEk7A2iBGR+hBE5ZNa3kUgUYAHYwG4cHGHYA/z1SLcbMTtHW97IynS0JyTiKvPyniyDpMxY9bx2XlUS0XLDEYTLUr3fpcMqV0KaAKI9FSGinrvufewYPASMiAoUVDaDc7VfYFi /4CWXq9p /pwAlUttcArOEvCGDmHk7h4IEBwQq61L5VISq6IWzIIMTFHtc7JnnHu5r38H9lUgxmD97y79UuzhH8zvyE+SqOTlAuE4TNWcCtPOnanLXeCOPEJEB1ahA1E7rOQ2N7skENy1GZkh2wcRdgg4r0Vh0Po+VKsU8NKAS/sitLpBY6pHKH33gKcbBXjucPbnyXwWvotSZ+WECgOoIo//WFjgYFvwt/2h09b6ZiUu15YUCX/58QnnsE0P/aHBwsqUrD2aCa5aVu/fkWIUphOHgdtVxb+mTJ85VkQkG0/GdEtEi0XHDDI7Pk9+OfXmEMST2J2aa/gumfQNagkZTsIFoEmjx97iHOTuXqPny8Hk8PGvFOIJMVuTmqTOu6arcTYUjelU2FfT6lYr7NXNO8XrX4+HgkgYNg+DpxjOyI2gNQQSrTXii5cuLP3dWu5hgxWTDa2+NeuWPtCvmt2r7hE8LwRghfkZMub8hzxjK2V3oxwJ4R6oRvFxLn/TAfIeV9n/LrE1mZiQXvkry/4p61cxBpZZZR6VKvA4CAVqw9L81vho0RaU+uHW/yxJIY3YLh7penIGfFtkvyuzPg3MTYOw= 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 8/3/24 3:02 AM, Vishal Moola wrote: > On Mon, Jul 29, 2024 at 07:25:14PM +0800, alexs@kernel.org wrote: >> From: Alex Shi >> >> To use zpdesc in trylock_zspage/lock_zspage funcs, we add couple of helpers: >> zpdesc_lock/zpdesc_unlock/zpdesc_trylock/zpdesc_wait_locked and >> zpdesc_get/zpdesc_put for this purpose. > > You should always include the "()" following function names. It just > makes everything more readable. Thanks for reminder, I will update the commit log. > >> Here we use the folio series func in guts for 2 reasons, one zswap.zpool >> only get single page, and use folio could save some compound_head checking; >> two, folio_put could bypass devmap checking that we don't need. >> >> Originally-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> >> Signed-off-by: Alex Shi >> --- >> mm/zpdesc.h | 30 ++++++++++++++++++++++++ >> mm/zsmalloc.c | 64 ++++++++++++++++++++++++++++++++++----------------- >> 2 files changed, 73 insertions(+), 21 deletions(-) >> >> diff --git a/mm/zpdesc.h b/mm/zpdesc.h >> index 2dbef231f616..3b04197cec9d 100644 >> --- a/mm/zpdesc.h >> +++ b/mm/zpdesc.h >> @@ -63,4 +63,34 @@ static_assert(sizeof(struct zpdesc) <= sizeof(struct page)); >> const struct page *: (const struct zpdesc *)(p), \ >> struct page *: (struct zpdesc *)(p))) >> >> +static inline void zpdesc_lock(struct zpdesc *zpdesc) >> +{ >> + folio_lock(zpdesc_folio(zpdesc)); >> +} >> + >> +static inline bool zpdesc_trylock(struct zpdesc *zpdesc) >> +{ >> + return folio_trylock(zpdesc_folio(zpdesc)); >> +} >> + >> +static inline void zpdesc_unlock(struct zpdesc *zpdesc) >> +{ >> + folio_unlock(zpdesc_folio(zpdesc)); >> +} >> + >> +static inline void zpdesc_wait_locked(struct zpdesc *zpdesc) >> +{ >> + folio_wait_locked(zpdesc_folio(zpdesc)); >> +} > > The more I look at zsmalloc, the more skeptical I get about it "needing" > the folio_lock. At a glance it seems like a zspage already has its own lock, > and the migration doesn't appear to be truly physical? There's probably > something I'm missing... it would make this code a lot simpler to drop > many of the folio locks. folio series could save about 6.3% object code... Anyway I don't insist on it. Just want a double confirm, could we keep the code size saving? :) > >> + >> +static inline void zpdesc_get(struct zpdesc *zpdesc) >> +{ >> + folio_get(zpdesc_folio(zpdesc)); >> +} >> + >> +static inline void zpdesc_put(struct zpdesc *zpdesc) >> +{ >> + folio_put(zpdesc_folio(zpdesc)); >> +} >> + >> #endif >> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c >> index a532851025f9..243677a9c6d2 100644 >> --- a/mm/zsmalloc.c >> +++ b/mm/zsmalloc.c >> @@ -433,13 +433,17 @@ static __maybe_unused int is_first_page(struct page *page) >> return PagePrivate(page); >> } >> >> +static int is_first_zpdesc(struct zpdesc *zpdesc) >> +{ >> + return PagePrivate(zpdesc_page(zpdesc)); >> +} >> + > > I feel like we might not even need to use the PG_private flag for > zpages? It seems to me like its just used for sanity checking. Can > zpage->first_page ever not point to the first zpdesc? Yes, the PG_private is only for sanity checking now. But zspage.first_zpdesc are still used widely and must point to the first subpage. I believe we could safely remove this page flag, maybe next patchset? > > For the purpose of introducing the memdesc its fine to continue using > it; just some food for thought. Yes. Thanks a lot! :)