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 18263EB64D8 for ; Wed, 21 Jun 2023 13:41:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5ECFE8D0007; Wed, 21 Jun 2023 09:41:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 59D888D0003; Wed, 21 Jun 2023 09:41:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 465188D0007; Wed, 21 Jun 2023 09:41:44 -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 39CA18D0003 for ; Wed, 21 Jun 2023 09:41:44 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D9AE2A083A for ; Wed, 21 Jun 2023 13:41:43 +0000 (UTC) X-FDA: 80926867686.28.5D597D5 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by imf16.hostedemail.com (Postfix) with ESMTP id 687C1180013 for ; Wed, 21 Jun 2023 13:41:39 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=sberdevices.ru header.s=mail header.b=Wi2tbOxs; dmarc=pass (policy=quarantine) header.from=sberdevices.ru; spf=pass (imf16.hostedemail.com: domain of AVRomanov@sberdevices.ru designates 45.89.227.171 as permitted sender) smtp.mailfrom=AVRomanov@sberdevices.ru ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687354901; 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=oF9EC/59syy+imHfhHbD4ox01r0Kl3E+5auyHknGjvg=; b=kRdzNeBOknIuZ7cqkejTXtVn3iaxrKmPhDdL4/6evOUoMLomZkSXssDpZaz2F8W27IAfI9 LtKljyc2DCHyMY1ML/1cRUIDScE+p7PJwfqSE8C7EGEBKvwP01BGXqLuq5GdPitwDGKZH3 9wYthB91Y/N/dw+XQWYk+TXQDopdL/E= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=sberdevices.ru header.s=mail header.b=Wi2tbOxs; dmarc=pass (policy=quarantine) header.from=sberdevices.ru; spf=pass (imf16.hostedemail.com: domain of AVRomanov@sberdevices.ru designates 45.89.227.171 as permitted sender) smtp.mailfrom=AVRomanov@sberdevices.ru ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687354901; a=rsa-sha256; cv=none; b=0D384SHpPaNxwrJoPOuvob5Gz1iWJgAZ2eumSloUxFuKjsLydeSnIdRiNQXv1EwVm/Xv6x Tpcq76WbRzt9dQSnEIzNZgWcejHYLxNrzHCKkzTB1GVL1WLR7A4/wd/QiVMPCiP+KbnGU4 bFGEC3onrqXJcNNGlQpZSE8Nec2ATYE= Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id 41B655FD90; Wed, 21 Jun 2023 16:41:37 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1687354897; bh=oF9EC/59syy+imHfhHbD4ox01r0Kl3E+5auyHknGjvg=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Wi2tbOxsocBljiyT5yJODzCEG6fBVirWEvBFH7jU/zPG/4U2fLASaV0ATX3ycxQJ2 KdtPQmvYYLtzlvaHZ5qq7VRWJzOJYv9RQaU9JZdps0MqRv3wsVCELNHh/El0ftqfRc 1Jm27xrVYar0fLrIRoxLT5rnsdWBcovXQCzCiX64wM+m37sbKhQDrKTNo1VQfxP1yo jTDJllGCKWNT1NiugR/2DHyIAx8HvBIIDIkuDIpOyT+bES/ZPMPbxkTSu0A6pYZEoz JI2D8E3+Q1QbVISmymSzzl1vtM++DDBTWSUbc6v75RFqUW58aqg7RdfdhvtnioNiym LfQ21CDZTrkSQ== Received: from p-i-exch-sc-m02.sberdevices.ru (p-i-exch-sc-m02.sberdevices.ru [172.16.192.103]) by mx.sberdevices.ru (Postfix) with ESMTP; Wed, 21 Jun 2023 16:41:36 +0300 (MSK) From: Alexey Romanov To: Sergey Senozhatsky CC: Minchan Kim , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , kernel Subject: Re: [PATCH v1 1/2] zsmalloc: add allocated objects counter for subpage Thread-Topic: [PATCH v1 1/2] zsmalloc: add allocated objects counter for subpage Thread-Index: AQHZortECyHNmKOx4kiy6hdprH0m0a+TTmOAgAALNICAAbQNAIAABsUA Date: Wed, 21 Jun 2023 13:41:34 +0000 Message-ID: <20230621134130.tm2oucg5eskelwzr@cab-wsm-0029881> References: <20230619143506.45253-1-avromanov@sberdevices.ru> <20230619143506.45253-2-avromanov@sberdevices.ru> <20230620103629.GA42985@google.com> <20230620111635.gztldehfzvuzkdnj@cab-wsm-0029881> <20230621131716.GC2934656@google.com> In-Reply-To: <20230621131716.GC2934656@google.com> Accept-Language: ru-RU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.18.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <92FD89CDCBE3784D961EF788F2599752@sberdevices.ru> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSMG-Rule-ID: 4 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiPhishing: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.30, bases: 2023/06/21 11:37:00 #21545586 X-KSMG-AntiVirus-Status: Clean, skipped X-Rspamd-Queue-Id: 687C1180013 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: dtrpurdy9tpwcj3n9j3gpjrgz6cmnz8r X-HE-Tag: 1687354899-107616 X-HE-Meta: U2FsdGVkX1+IrIYlzy8DSiJMHBMjQr7UckoMNTqrgpktRe16h6TlUYCeTR//NsCcw9+zBxGlF9AuqWcZYfXqDk2r51XTF7meZEAuFoVPpin+kKFxEqdFy15WdVRVXG/FLViyAp5Js8ZOKABlmZemhQsVKk57SPcz8WVdveRwkTdq8VLA4/ZzKXTj6BbiNGZTZpzzYLgnlHJS4dJQXK96jjKBDydBcKLEOPdh7jeUv1EgzARZjxhhlcZtkRdJV+eFJDFpo18ARrelO6z4DRlW2e2V/hIXX31o/Slj3zGqunSvwhs3dVS1wGOQi4uNNUjED/OsCjWCv40scPJcE6JkhPfzYUfHLgG8Hf4uhSCJd1rfqEpbZev8qmi/FLtD8yliXOL6gWmcLnU8rIWJKUT/A00ojt4Zb6HV9bO40ffRrNXUITlSqF/44EkVFIvFmBLeYPRNOm/IIE6eXWz0V+aAvED46VLv+oP2zySYgY8dZG2QT7lL00Cb690D6FdyB7di8OJ5uFLphejRxUIdDN8bCC/y02hxU8T15FUj/TM1U+LlzkvPaOGKNJxxgDjetASyyqslkmnXb58AvK6diDyb9xQ7N/hUjFp8VdqO9IxBns5KjntjYTjOhI578hKdRSfWIk5W3m8IWnCCPJyTeywlMG3OQBE3Cida5wTOj3usZ7JoHFRSCV1IKhC7TmpnxkHbEcu5ibMS7//i0XaoiFThHsYdMCJVXzYCc83ikX79CXlCX7y4wdL/K7agbUIBim9H845UcvidXOjawznhh48Z7qLtfPZLj8+jQlHmE85vdhL0jHlVE3pOdG8nlmqiwGiUShNh6K2h8kiu6dBWRhP7K8TcxrIw1tqe+M+FHB2BZKFxtcTpwZ3Dt4eAiJuXP8EdvVeH+z3X0y2xfjDImutaG9PByz8YG63oYkahonSFsrjxbnfPcQk0cpFlLbhLy4sOVExMbavdhnLFJu5eLGT aLkK9S60 /YXx41Jguuz3O8wW+jUPpwow3yTcieOgOuuAWN3RzFO5G3czT3J1+DwJIOMgQerQOGAWDqWf6rGUDwx4iYbfMPEL2+0bb4bbMFvbF1rT+yj6jZSD5yrXK687VOFJ39aykKNFbK2AB6Ol7c/oz48lIdSuP41CuiMqqokF3U1TXIjwKmk0dDmwr5xGl7bKf2e0XOlx+Nbt8MmQ1eo40wkNExJMrwXTtkGg2ZEjQ8k8poprYwm5RW3iUMwhlGNEmaX4BACOVU/LX7pMOO+v1Y0aENm43Scys1CCFL0ABzh2N+61tYifk8jj5oZfQLvwr0LBVyVl4IXq/zTIK7hvXkcUnPBkHhQ== 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: Hi! On Wed, Jun 21, 2023 at 10:17:16PM +0900, Sergey Senozhatsky wrote: > On (23/06/20 11:16), Alexey Romanov wrote: > > If sizeof(unsigned int) >=3D 32 bits the this will be enough for us.=20 > > Of course, in rare cases this will not be the case. But it seems that > > zram and kernel already has similiar places. For example, if page size > > is 256 Kb and sizeof(unsigned int) =3D 16 bits (2 byte), zram will not > > wotk on such system, because we can't store offset. But such case is > > very rare, most systems have unsigned int over 32 bits.=20 > >=20 > > Therefore, I think that my idea is still applicable, we just need to > > change the counter type. What do you think? >=20 > My gut feeling is that we better avoid mixing in architecture specific > magic into generic code. It works fine until it doesn't. May be Minchan > will have a different opinion tho. >=20 > There can be other ways to avoid linear scan of empty sub-pages. For > instance, something like below probably can cover less cases than your > patch 0002, but on the other hand is rather generic, trivial and doesn't > contain any assumptions on the architecture specifics. >=20 > (composed/edited in mail client, so likely is broken, but outlines > the idea) >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > mm/zsmalloc: do not scan empty zspages >=20 > We already stop zspage migration when we detect that target > zspage has no space left for any new objects. There is > one more thing we can do in order to avoid doing useless > work: stop scanning for allocated objects in sub-pages when > we have migrated the last inuse object from the zspage in > question. >=20 > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c > index 02f7f414aade..2875152e6497 100644 > --- a/mm/zsmalloc.c > +++ b/mm/zsmalloc.c > @@ -1263,6 +1263,11 @@ static bool zspage_full(struct size_class *class, = struct zspage *zspage) > return get_zspage_inuse(zspage) =3D=3D class->objs_per_zspage; > } > =20 > +static bool zspage_empty(struct zspage *zspage) > +{ > + return get_zspage_inuse(zspage) =3D=3D 0; > +} > + > /** > * zs_lookup_class_index() - Returns index of the zsmalloc &size_class > * that hold objects of the provided size. > @@ -1787,6 +1792,10 @@ static void migrate_zspage(struct zs_pool *pool, s= truct size_class *class, > obj_idx++; > record_obj(handle, free_obj); > obj_free(class->size, used_obj, NULL); > + > + /* Stop if there are no more objects to migrate */ > + if (zspage_empty(get_zspage(s_page))) > + break; > } Yes it seems my version is not as good as I thought. Looks bad for an architecturally dependent PAGE_SIZE. Your version sounds good. In general, I can implement this option. I'll test this and send patch this week. --=20 Thank you, Alexey=