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 C30BCC636CC for ; Wed, 8 Feb 2023 13:56:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D6836B0071; Wed, 8 Feb 2023 08:56:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 25EAE6B0072; Wed, 8 Feb 2023 08:56:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10BB26B0073; Wed, 8 Feb 2023 08:56:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EFD0E6B0071 for ; Wed, 8 Feb 2023 08:56:31 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B192FC0CDC for ; Wed, 8 Feb 2023 13:56:31 +0000 (UTC) X-FDA: 80444274582.11.EA649BF Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf28.hostedemail.com (Postfix) with ESMTP id DA82EC0010 for ; Wed, 8 Feb 2023 13:56:29 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=lXSTV9mP; spf=pass (imf28.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=42.hyeyoo@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=1675864589; 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=MbjCxpd1Xp38e5yEBPXCZTJ4aQSxWow0JH4h9SbLGXs=; b=eWf1FhEAkk2G3hC4oiyQu0LlFoRZkJ8paLnfLzzZCNvbMJdfY8+zvASFUtf0n9UE0Po7fT mCGD14daVRUaRq/XYV6wy4Efb8GXdLri9IdmwhLTlcIj8pVa78nu8OGZ9/5oCh9sTwMoSK RNlLo4WmnwIuE12JjRMWMQ7NltjJi3k= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=lXSTV9mP; spf=pass (imf28.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675864589; a=rsa-sha256; cv=none; b=spjPM7CNbO7QT8OLyrjDnUHS4Usgko3/XyZQ1KxJjLs3Zpr6P7OOT1sKwdhEi4sCrb0CSM it2exV6ZqhTwQZ74vdjPC1C1uTNowopouI9xt92J9rWk1zNz+gu8nLmJczMafgvU9vuQQD ipumLDwWFQcp6wTNXcY1U6lo7FPk6l8= Received: by mail-pl1-f175.google.com with SMTP id g13so14513903ple.10 for ; Wed, 08 Feb 2023 05:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=MbjCxpd1Xp38e5yEBPXCZTJ4aQSxWow0JH4h9SbLGXs=; b=lXSTV9mPU2L37vQpxhlnyhmClaA15XL3GB9jC0eY/OX6tInDYTWyHXNYu+83r5y9mz XInocONldXyN+odjFGXSObiCLl/55ZqQb//SjAHL0qqU2Elepv98yyeG9hZLijNZzP6d YvE+GSI+5rX2NJYTTDthQa77m54ctlwFDzAsw+PeHlEbk4YW9vNEkdBPjY2MdPV6hDSP QbOa/wHvRpO6QgMLJR8tQUrV90E5Uco2LgOuBZm5PPYr0iYafESvWArTLbHqNCQ+ecBA mbNBe8+w6Upoh/3MywUfMiRQc0vawmdy1AHiYGy4sGbSb8FOh6FLuPIvyjuAxNr1TzqD Z2nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=MbjCxpd1Xp38e5yEBPXCZTJ4aQSxWow0JH4h9SbLGXs=; b=npP7HLKCUsIWfrBw8k0rZ2ZlsYOqHcRG5cx7UDYeF0FsIaLbw57LmtJ2eXEdke8yhR 2Pd+nBqsbnws4XKnXNuZoLWN+m8s6N/7Lr49qaH/kw07OlLMad+CuAjG1mfnIx8nldPJ zBrTVEvrkYLuxDLWmwFkbJge/cADHZFnpdprtev373TFMo+9LrD7r+5Z6r/cUXhzBh9c WDHguGBb2GPWQBtHEUXdwz5TQYIpsfoQ+JmGMsYn9kMJkHapkChlMbYpV3LXnLNZZZ3n VO//CzGTnNzr96qSv06GMJ0IIbTtui23CNtC9ynvuPTK9Ntw7+dUbPeKiVCCnoFtAQyM vlRQ== X-Gm-Message-State: AO0yUKW+Z2/rncf+9m4v8shHbCQ5NHGqHWFxol9PVvGmkZOIC/rvR+rx PG8AnuZa/7YP+2B2wNARoL4= X-Google-Smtp-Source: AK7set95H8ek/YM3KqQNTOzMLrRwgIEGY5xHgnTz1DP/okx0woSEjQjF6dbp8nw39TEoplPkT9mkmw== X-Received: by 2002:a17:902:cad1:b0:198:f2a9:a973 with SMTP id y17-20020a170902cad100b00198f2a9a973mr5723274pld.17.1675864588513; Wed, 08 Feb 2023 05:56:28 -0800 (PST) Received: from localhost ([2400:8902::f03c:93ff:fe27:642a]) by smtp.gmail.com with ESMTPSA id jj9-20020a170903048900b00198bc9ba510sm5794042plb.71.2023.02.08.05.56.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Feb 2023 05:56:26 -0800 (PST) Date: Wed, 8 Feb 2023 13:56:16 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Matthew Wilcox Cc: Vlastimil Babka , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , HORIGUCHI =?utf-8?B?TkFPWUEo5aCA5Y+jIOebtOS5nyk=?= , Joe Perches , Petr Mladek , Andy Shevchenko , David Hildenbrand , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Alexander Potapenko , Marco Elver Subject: Re: [RFC v3 2/4] mm: move PG_slab flag to page_type Message-ID: References: <20221218101901.373450-1-42.hyeyoo@gmail.com> <20221218101901.373450-3-42.hyeyoo@gmail.com> <15fda061-72d9-2ee9-0e9f-6f0f732a7382@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 4q63dsgkc6dp77a7fn4m74wr6gey8bfb X-Rspamd-Queue-Id: DA82EC0010 X-HE-Tag: 1675864589-146459 X-HE-Meta: U2FsdGVkX1+69xHtA+St3mnebSD90E8QsdISfVB3rCOxbWPe6UJXaSHJzovjOdqqkyXRLoFV2Ls6oRrQjFwpvY/sjeXVhgTB9yHwLxNESad20+/XtssTdqCHK5ofGJtJSCQwNsetNitOiKWfUOGLMCNKpvfJXkNOiZ5IyzgnVN48F3nRJxJzwpQGuxJ0ab6zhsAiopxP3JRaEh2A/4u4YgsG4Ti+/SgXjRzBIfPBRhM27l4zE1GNku5bzqsTw6AUW17yS20NWkBf1wAzQ5ksaiOCkHsuKf+DDDtE7vl/F/fIxDamgNHcDAbiS1AcfadPt7peFMELE/mtnEBBLtJX1vhhBhqn8M8jTI1T6iQHuyz7u4ag01QWcYzLXFSGfjONkGwYO2l9GemxKKpFYaSp435rEOmCY6W9feUfzhZKU1C373rgFI+MRc/PcMvfy4HekT2JYqM/Wetk0BJKMVllgiHBQn3vb50EC6gbrOx1zX/EpxYWlGVuhc9+iheLmRHqOZ2rUe+LU4SfuBHrDKfxVLw1e4b7upK+43upDmubkWl540S4OTigbGyVRCX8SyBeRau6uLLu5ft+pn9T2gxMdV3rvtG4S2DUXbxtz0a93+WMzGDuWo5zcWRhBzreFKW8SkkReee0irsakoH87srT0+vC0VMHe0L8iCUDCtYYbHGXGVkk4qD5gch6IIcUkpiHj0k+t25Zq4CqfcG92kTukpyNyQQoS9TRAys8FfiIg4S/NrBRsKUSG3sF2pDNXbZpigsVaPIe8WAWSsZQCduQ7JUVuAAPZn/Oej9MvjDsaitCiLBMPol4XLiV8JSMHoeewZr3cSCXS4UjeVBA4TGbzOXe0O2eVlNUXiN0qzG2hL63hz00j+0blGcAL0R0SoRp5Ue+9lxsbaaCXhHg7LYyvXjEXs33tqK0Du7Z1+he26I75+hzQxxczwpw3jLVCjBYugcksLyMf1979lVj2Rr w9pWdmCS F7hUmvr7LWRm/mlyxZqTO7fExkDBQix8NNTqEAKDQRJrM/J1p+aNcEg0s0rqWBS+O813c0aTVPXBSqTyJXDvHcRhHHWrteEIvCNI7ZEB8mHrJSLcdajr8s9QYgdnJ7+UMgPrI/fPH3X//5LiOPBBQlZsdNh6vBeZRkedcP8VM+QvM66FBXIEwEjxUlF/2OtnnVU85R6UbNjnBvPmDqJW2NC3Ft7TPKh096sGUaPSRwPtNhODfmNU75RxCDsr2ghHrot0WgtzGiRp9wcpEox2Z0XviHFqiWzjFyykrx+XafMxAYZCOtCJbgddOOnZMKKmnHsqDgiGJ59V6d1bPCp+qJrOH7tlYAkoaBwTPZpBemcdfN9IlGhSwxpakvg6ymJfeJUOD/NLvBx1vK9LjNq85chEMBl+ad1XsQpzZ8hxlCGMCEQ0Zximp2b+FGc9R0i6r/oyKTEUbW9IYcERZONdZ/KsLVm0+YVeaBtIBB/0uT2i4YnrEDhqN4/5G3rKny49Mlwa1 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: On Fri, Feb 03, 2023 at 04:19:32PM +0000, Matthew Wilcox wrote: > On Fri, Feb 03, 2023 at 04:00:08PM +0000, Hyeonggon Yoo wrote: > > On Mon, Jan 30, 2023 at 05:11:48AM +0000, Matthew Wilcox wrote: > > > On Mon, Jan 30, 2023 at 01:34:59PM +0900, Hyeonggon Yoo wrote: > > > > > Seems like quite some changes to page_type to accomodate SLAB, which is > > > > > hopefully going away soon(TM). Could we perhaps avoid that? > > > > > > > > If it could be done with less changes, I'll try to avoid that. > > > > > > Let me outline the idea I had for removing PG_slab: > > > > > > Observe that PG_reserved and PG_slab are mutually exclusive. Also, > > > if PG_reserved is set, no other flags are set. If PG_slab is set, only > > > PG_locked is used. Many of the flags are only for use by anon/page > > > cache pages (eg referenced, uptodate, dirty, lru, active, workingset, > > > waiters, error, owner_priv_1, writeback, mappedtodisk, reclaim, > > > swapbacked, unevictable, mlocked). > > > > > > Redefine PG_reserved as PG_kernel. Now we can use the other _15_ > > > flags to indicate pagetype, as long as PG_kernel is set. > > > > So PG_kernel is a new special flag, I thought it indicates > > "not usermappable pages", but considering PG_vmalloc it's not. > > Right, it means "The kernel allocated this page for its own purposes; > what that purpose is might be available by looking at PG_type". ie > it's not-anon, not-page-cache. > > > > So, eg > > > PageSlab() can now be (page->flags & PG_type) == PG_slab where > > > > But if PG_xxx and PG_slab shares same bit, PG_xxx would be confused? > > Correct. Ideally those tests wouldn't be used on arbitrary pages, > only pages which are already confirmed to be anon or file. I suspect > we haven't been super-careful about that in the past, and so there > would be some degree of "Oh, we need to fix this up". But flags like > PG_mappedtodisk, PG_mlocked, PG_unevictable, PG_workingset should be > all gated behind "We know this is anon/file". Okay. let's just try then! > > > PG_dirty 0x000008 > > > PG_owner_priv_1 0x000010 > > > PG_arch_1 0x000020 > > > PG_private 0x000040 > > > PG_waiters 0x000080 > > > PG_kernel 0x000100 > > > PG_referenced 0x000200 > > > PG_uptodate 0x000400 > > > PG_lru 0x000800 > > > PG_active 0x001000 > > > PG_workingset 0x002000 > > > PG_error 0x004000 > > > PG_private_2 0x008000 > > > PG_mappedtodisk 0x010000 > > > PG_reclaim 0x020000 > > > PG_swapbacked 0x040000 > > > PG_unevictable 0x080000 > > > PG_mlocked 0x100000 > > > > > > ... or something. There are a number of constraints and it may take > > > a few iterations to get this right. Oh, and if this is the layout > > > we use, then: > > > > > > PG_type 0x1fff00 > > > PG_reserved (PG_kernel | 0x200) > > > PG_slab (PG_kernel | 0x400) > > > PG_buddy (PG_kernel | 0x600) > > > PG_offline (PG_kernel | 0x800) > > > PG_table (PG_kernel | 0xa00) > > > PG_guard (PG_kernel | 0xc00) > > > PG_vmalloc (PG_kernel | 0xe00) > > > > what is PG_vmalloc for, is it just an example for > > explaining possible layout? > > I really want to mark pages as being allocated from vmalloc. It's > one of the things we could do to make debugging better. Got it. Anyway, the proposed approach is not compatible with this series so I'll try implementing new series based on your outline. Thanks!