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 B9ECAC4332F for ; Thu, 20 Oct 2022 08:52:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3688B6B0071; Thu, 20 Oct 2022 04:52:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 318356B0073; Thu, 20 Oct 2022 04:52:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2081E6B0074; Thu, 20 Oct 2022 04:52:20 -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 148C46B0071 for ; Thu, 20 Oct 2022 04:52:20 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D063E80185 for ; Thu, 20 Oct 2022 08:52:19 +0000 (UTC) X-FDA: 80040711198.02.80BBDA8 Received: from outbound-smtp21.blacknight.com (outbound-smtp21.blacknight.com [81.17.249.41]) by imf29.hostedemail.com (Postfix) with ESMTP id 4E75A120019 for ; Thu, 20 Oct 2022 08:52:19 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail03.blacknight.ie [81.17.254.16]) by outbound-smtp21.blacknight.com (Postfix) with ESMTPS id CF261CCFEE for ; Thu, 20 Oct 2022 09:52:17 +0100 (IST) Received: (qmail 17092 invoked from network); 20 Oct 2022 08:52:17 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 20 Oct 2022 08:52:17 -0000 Date: Thu, 20 Oct 2022 09:52:14 +0100 From: Mel Gorman To: Andrew Morton Cc: Yang Shi , Matthew Wilcox , Linux-MM , LKML , Brian Foster Subject: Re: [RFC PATCH] mm/huge_memory: Do not clobber swp_entry_t during THP split Message-ID: <20221020085214.7pgvylgxkojbiuat@techsingularity.net> References: <20221019134156.zjyyn5aownakvztf@techsingularity.net> <20221019161810.7510df1f37658a2b71c5e3a7@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20221019161810.7510df1f37658a2b71c5e3a7@linux-foundation.org> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666255939; 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; bh=Q152pgKpvF13sFF8WIV138r5EWMJA0mm+MW4LzuifQ8=; b=OMR357snpRBAvjiL/8HFsDgxkVMTs0XqUmSfzDbzUnlTjsymJ+f5+eO2qEUNER+3PHecgr SJPLmfVIW6IKya3g3WwBR6ux3GsUnux0SWDb/4WEjfNGQPTXBWV4nqr/VJ2lz4Mho24JCv XFcQjtknC8pCy+y+cvASOih3u9BGeTY= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.41 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666255939; a=rsa-sha256; cv=none; b=g3KVo3UAJuv+R/xxRjlKgLLw/XUK6Ib3BHGis6fvhVsGxWElSSQLSEza6bpvR6luXhGISO B5L8G/KneCthNr4Pv0YbapAhR5S818KBeR7dOw1cmTB4+9IQqjliIv9pDupC/nBHqTWyNw IoUv2FTl0uYrf/CV+s5y1JkKTbezQmA= X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 4E75A120019 X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.41 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none X-Stat-Signature: 4iimbm61rzmwce7o58upnch51up14i7d X-HE-Tag: 1666255939-45549 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: Adding Brian to cc On Wed, Oct 19, 2022 at 04:18:10PM -0700, Andrew Morton wrote: > On Wed, 19 Oct 2022 11:17:14 -0700 Yang Shi wrote: > > > > The intent of commit b653db77350c patch was to avoid the case where > > > PG_private is clear but folio->private is not-NULL. However, THP tail > > > pages uses page->private for "swp_entry_t if folio_test_swapcache()" as > > > stated in the documentation for struct folio. This patch only clobbers > > > page->private for tail pages if the head page was not in swapcache and > > > warns once if page->private had an unexpected value. > > > > It looks like the same issue fixed by > > https://lore.kernel.org/linux-mm/20220906190602.1626037-1-bfoster@redhat.com/ > > It is. > Yep, based on Brian's changelog, it was the same workload that triggered it as it happens to stress the corner case that hits the bug. > As I asked earlier this week, what about reverting b653db77350c? Why > do we care about the value of ->private for non-PG_private pages? I don't think we do care but based on the changelog of b653db77350c, it's part of an effort to either remove the PG_private bit or is a preparation step for casting page to a meaningful type based on context but only Matthew can tell us his motivation. There at least is some value to identifying cases where a referenced page has valid information in page->private that is not reflected in the flags. -- Mel Gorman SUSE Labs