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 6F031C25B74 for ; Thu, 30 May 2024 05:02:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C74736B0096; Thu, 30 May 2024 01:02:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BFB2B6B0098; Thu, 30 May 2024 01:02:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A75A06B0099; Thu, 30 May 2024 01:02:31 -0400 (EDT) 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 835AE6B0096 for ; Thu, 30 May 2024 01:02:31 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 36EA0140D98 for ; Thu, 30 May 2024 05:02:31 +0000 (UTC) X-FDA: 82173866502.07.8176258 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by imf24.hostedemail.com (Postfix) with ESMTP id 614E3180003 for ; Thu, 30 May 2024 05:02:29 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=KZFO85dl; spf=pass (imf24.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.178 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717045349; 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=E2rzSDb215bjTuDO8BCbneyrOEpC1jpSqJofLgkhMlo=; b=TcvgIj38npvK+DqEio4ePgeVkfsry7Lg06JiqqSJNFDeyPu285nV9DBZr81X4R+S6BgtqW TT6mnVfJWk4kEEZZiafTXMbqeFgf+BtG1C2ty0PJgizYxHXfqcTteSTN291Xg5en4g3kzY D3xvDanagBwXw4HSL8PPczq0WqjdIfs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717045349; a=rsa-sha256; cv=none; b=Bb/bcqsJe6wuq6ILioaMCDpuKAGqxO7vjXYfSgNdbWItZMoOfZok8aNgRgTdHccnNQ5H0q UMwaT5Khz/p140CM3wBO6G+AddIYo0+fxY2RGD6giGU49bOaBmOEDUjRGUIgWEffVg83WV MRRmrm1i/G5Y881d37OC3tISxTmXM2k= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=KZFO85dl; spf=pass (imf24.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.178 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-6f966840af7so459191b3a.2 for ; Wed, 29 May 2024 22:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1717045348; x=1717650148; 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=E2rzSDb215bjTuDO8BCbneyrOEpC1jpSqJofLgkhMlo=; b=KZFO85dlUMYPZcTcBkFlfBYsJdcbRvMZRJwlJhYMz+PnLfNr9B/5nx9mPmsrRZpVwj 0kynIs/87RCjUAxGQ65HPheq01D0ZC6DMLXoqqgrh+as53JjQjUMjJ6/xSeSUeLwP+mB 7Vekv3YXD6PTZSkYd021yZToNhZ7ZPHIi6tQ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717045348; x=1717650148; 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=E2rzSDb215bjTuDO8BCbneyrOEpC1jpSqJofLgkhMlo=; b=VwPNRrYvP4msHP5CJ9cTAMNVTW5XTbBBu8v546gQe6h6N2bc7C9AdyjOntrgjiuvk4 35OqJ1MNNy5D+GPLSrYtKL8bYEhghStXzm9l2QZHggOSDWNTwhk0pE+nnSpzy2zweOZF qnStCdxVq2FLuWXPnZWYkpjQ1jYx4c7cuRtlRc3e7CPo+QAZLWJ0Q/Dg4rV0ST9WJEOo +trjH1LNko0DaJduQcNsjSDx7tfm689qhRg/PsPncI1o9P/uSsR43+aCr0vCqnCJPErn WGNvfsa3vDfh6D1uZ9VrD0Rg3lZ/u6WmMLuqAwEMud4G1JcQO564BuLW3mV1fJCrSTvY 1Daw== X-Forwarded-Encrypted: i=1; AJvYcCV69x2G/7MhR4wbuH0JvpLFsr5fqwwS10AkR2qPkVnB4VvF4qxUPE8I0P0Ct1tuCvdwUG6PhjzXQ7GJSb5bJ4RVajU= X-Gm-Message-State: AOJu0YwOmCo9OGzM2OKgBjzRe+rWo4bjQq64fy5/womWYASEeVAMCZZY /CqZ/eUSy4e4XYMCHfF3lqCBBF4XWZZcE2/DWmfFdhKFHWm1yHq+uC3uxGGU9g== X-Google-Smtp-Source: AGHT+IHN8ur5W5Ju5M/+GYL/UfE5kg+ae0967SpV28BilHbdephBhNKqKAOeEMhgmvM9yQIP5TZxRw== X-Received: by 2002:a05:6a20:a120:b0:1ad:7e4d:5b81 with SMTP id adf61e73a8af0-1b26452b4b2mr1287569637.5.1717045348180; Wed, 29 May 2024 22:02:28 -0700 (PDT) Received: from google.com ([2401:fa00:8f:203:52e7:354b:db96:c366]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-701b7cacca4sm3875395b3a.37.2024.05.29.22.02.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 May 2024 22:02:27 -0700 (PDT) Date: Thu, 30 May 2024 14:02:23 +0900 From: Sergey Senozhatsky To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , "Matthew Wilcox (Oracle)" , Mike Rapoport , Minchan Kim , Sergey Senozhatsky , Hyeonggon Yoo <42.hyeyoo@gmail.com> Subject: Re: [PATCH v2 0/6] mm: page_type, zsmalloc and page_mapcount_reset() Message-ID: <20240530050223.GB8400@google.com> References: <20240529111904.2069608-1-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240529111904.2069608-1-david@redhat.com> X-Rspam-User: X-Stat-Signature: 4gx1rh6mzu5wr797ey53absjg34j61ar X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 614E3180003 X-HE-Tag: 1717045349-271908 X-HE-Meta: U2FsdGVkX18LvwXuReyB9zsMxe44ZPquojFSi3EdrTk5S5sY0Te1YwvXh7+2mQ6jp46KevhLkc5EKTGUa8IX3JitDyQf0mwlXJwwFNn3mTSysoHfU9IiwjkfpLEWyk064QgrarqRhuyX3vU93d/aHBH3O1g+edSkmz178wG8yTfFb/0KuY5vS/YorGocb8JsqvZcZnhXq0VndFY3bmRKoNGnehvyrYWKcjKvtVIVzuRW+g33JcMzZkTobp7VfU9BbC8/DqFnm31xwxLwCS23g2nU5K+HDvLUl63rB5eucAsU5b0FvqH3XswMm8D/IWG3D0xRM2r+SIRVQzpftOqFgj15U9iA1Zsxn4Qr/AV3+sy2DAVsHHwNREvRV8ynUseU1FuHK+g5QSx48QF42xV2V2r+OSLsquQFDXvHWBDDU5p1FdXB/OkBlodlrcA6AC19Dfrbvd4VjU3ZKR+uhE3a1WCoTFn4jjNkkoYwrOClL5EKsU9B5SbAORvLCChvtr9JtOpmjqEaL88XEU1lVKbaVmjXkm+hf8X2YEHVroyudOebIB2j3cguM1rvP3ok4xtnBA47Wqy/lXs01DA8h6plIbs4iRh+hXOhoOrJzWzvlb3AwLjNr2+3CvFMDnToEuA/XN+GiZ/2wkeyTf6QXz+PC74b0eokHNo7hf9ta9NCUWasPHkKH1QwalUNOT1xtb3NXOq7iuMwsP9pNfG1Y+wLzn13Cp6Fxwiie8UsuSkrL6Fz7hbziXrRaeBEB/zHh9/+G/7V6yDfGrmIxipKdoBP25W5oHzkx/6GrhNBgvydERXrKzu5EtU2W4f08EeJTA3zvvqFhqcDJL6utMbvwbNJSCmd6Op4n6JUbc7YHPP8cM6LTlO2dRHXmKE5EwRstVzU/GZviVbtba/sgdSNPQdR2FqN6hpQs9S2oaEUAjtRFMm4+sIxC0CKzmpHVWoPama5l9o1aETjS6MpLYdzXMg gRf7ehvb O8Wbs074o3liTJfGQTDUQ40bx1jiR8v89O74SdqMMvqMOSLvqlHZdiIKt4YGY/FlzlOH0VJ/eRgc4Mw1Vwt3tOT5L7xx1Z/7HDHfL4If1c+2R81jS0dB4rtRyZn2Ckl/6H9wlgx5ZgMp+Y1ok3XxJWGzkiDYGGF4GY/Xc3MgtkZv+vaVk3laWjpxWP7dfgrFf2xoj4IxMH2hZ9QfdfDxKq4dgt8MTxyuB/o6Er5WUl6qh9cFT1DTSLePHj6HjIXyGao4PBmp3UbMiAmjNEmQv5tdh6QqGC1fOPijzlNY9mySIKwoEbgi4OBozC3YMInIJfMHe1gNcBq53pbQVQoVipMZRD8S10S9D9mAJqaY7PQZf83e6wHcs5whlykdxPRqoTvaNGtv8dOO8qrw1Ogm1rbq1tMG3L/g66KPczQnhZyX6B457lLEUMQFgoxKH/et2pCnecHt70gjGX1+IOcgcNKjG/NfrWkIDRf2HYMnEtoJzzAEghksjqpwk0giHOf1HUmvNp1OSgynGf1RFj6II3gdQxI2UiXs0mE8oj92GJ+c0HcZ91p6DmNV31TErAxHZRarOF6IquPBAuhHI4heY54LYs6X06a55gsHy1ejXJDS//Ix9cMeDl6Zw2OjuaaLoUo0ADx2dXqmVvaknGSwyOYfneE5lzOkyZ+29xl6fgxr455XVM0eT0Eehiel33oeTn0SYMnZpWEItUfNLkSfcAn7sPXyE88ryvTan 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 (24/05/29 13:18), David Hildenbrand wrote: > Wanting to remove the remaining abuser of _mapcount/page_type along with > page_mapcount_reset(), I stumbled over zsmalloc, which is yet to be > converted away from "struct page" [1]. > > Unfortunately, we cannot stop using the page_type field in zsmalloc code > completely for its own purposes. All other fields in "struct page" are > used one way or the other. Could we simply store a 2-byte offset value > at the beginning of each page? Likely, but that will require a bit more > work; and once we have memdesc we might want to move the offset in there > (struct zsalloc?) again. > > ... but we can limit the abuse to 16 bit, glue it to a page type that > must be set, and document it. page_has_type() will always successfully > indicate such zsmalloc pages, and such zsmalloc pages only. > > We lose zsmalloc support for PAGE_SIZE > 64KB, which should be tolerable. > We could use more bits from the page type, but 16 bit sounds like a good > idea for now. > > So clarify the _mapcount/page_type documentation, use a proper page_type > for zsmalloc, and remove page_mapcount_reset(). > > Briefly tested with zram on x86-64. > > [1] https://lore.kernel.org/all/20231130101242.2590384-1-42.hyeyoo@gmail.com/ > > Cc: Andrew Morton > Cc: "Matthew Wilcox (Oracle)" > Cc: Mike Rapoport > Cc: Minchan Kim > Cc: Sergey Senozhatsky > Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> Tested-by: Sergey Senozhatsky # zram/zsmalloc workloads