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 1FEF7C27C79 for ; Thu, 20 Jun 2024 03:59:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9CDE96B043A; Wed, 19 Jun 2024 23:59:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 97DE36B043C; Wed, 19 Jun 2024 23:59:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81F6E6B043D; Wed, 19 Jun 2024 23:59:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 635376B043A for ; Wed, 19 Jun 2024 23:59:49 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D5C77C1746 for ; Thu, 20 Jun 2024 03:59:48 +0000 (UTC) X-FDA: 82249913256.04.E5E77A1 Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf20.hostedemail.com (Postfix) with ESMTP id 163FD1C0007 for ; Thu, 20 Jun 2024 03:59:46 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=xDo4iAxU; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of hughd@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718855977; 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=HBwc7mPCGMDxzjg6zCv5GvwP0k9UEQfjFaEZ4/talLE=; b=hviujdOjR/oqT5ZkTiGzpQyy383LvlEugHA3Uck8JRJgkDA0B704E6tltle3hD931PrLK+ hkQedTPZCjBkulxTs5PPwASXWku710GSAZbQdILuB/0Qx0GWDLtjA8utprK+ixUz+54b6R O+gyGJketWgYBT6TMMGJiCEsBVurmsA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718855977; a=rsa-sha256; cv=none; b=iaVH8GGuj2eAQgVW6ykDAZVD04R6qPlJ3kgnLBqJlDWd143YqmtCtfzNMuGdSsOXWLRLuB x/Lwh0zB6R2WGHCz4Op4sUefkgJx05HfpmJd4igCwq1x/az5bzAPMXGHdzdfKDT3KuIt2W 4vTiM013B0HZOazFj0Gr/NIeS7Y1QxU= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=xDo4iAxU; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of hughd@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=hughd@google.com Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-dff06b3f413so385541276.3 for ; Wed, 19 Jun 2024 20:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1718855986; x=1719460786; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=HBwc7mPCGMDxzjg6zCv5GvwP0k9UEQfjFaEZ4/talLE=; b=xDo4iAxU/jm1JkffJAzTdsAPDXfk1xzJyxnLR58iu6LUkdlmEm3UmAsepIrJce0U41 BaQRBY477atjlpqlTQUKj6mInFS5gYhZWW8PdHj8KEsknOTnfN+qeFv9mqJ2zfXR2SHs I/uq1Q9inGtYW45rwZpkDLnKAXIDuvHrfV+8rObEGaLsJ1JBTMOkIRooJ+z1wdA5zESb IMisl40B/TtnZ/9IpElFtC2Ms7zUeUMxzhWNnxFQLX2gPAbXLZx5TSdEEON9WSLMaStV 17366kEPCPra8VlPWC0j9jwuE4BcwIDvJpx2hYRJh8nkuvf2Yq/Tq40GGUOEJNaItS6B ZodA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718855986; x=1719460786; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HBwc7mPCGMDxzjg6zCv5GvwP0k9UEQfjFaEZ4/talLE=; b=Udfn4M/gcGVQ8EpI0aDCKuawjg57fTwtr51SFtcJLJ5/sRvJi24N8cXWSWHtDidbh4 phNAeGfVgLgNqf2WQvVGWRdREWkqNGEtcBoJYsvjrEZpiuGnW3GH7nLRBf1/SqBd2oZo 7WxVmvB5WrK+c6n78ENhdOKqolySJEbUwXo7M6edF/MOaT/GV0okNW05uiOV+IMxQ9ra tt7Y8DlrzhoMKAGS60irw4SH7m9bLtz8Dk6Nagd+nYgdFpqLFao7bYR9xLqt+L2c73rq 0XbJZN5qhT3EOdEwnJYqQNVpLelqFP+hvZGtfMzONPV6/WB5dI3+Tnf88ujeCkMaSG0Y yrxQ== X-Forwarded-Encrypted: i=1; AJvYcCUkTQYC1mtpG2Xu2W1hA3VP9E2Clg6AP7OzOk1rMcPERf27tE82dGZb79nVD1JUJq6RhCh24+lMRMnZZI8H/jYs104= X-Gm-Message-State: AOJu0YxQX0WLkcGQOXNedwCBQS+lFlh89O/xscaY5TnB9cxeyWxBWi32 Vk7KNeAKvTFC1tWR5gvSEDImBkS9g+oOITf4w2LuQsnhF5JGdIpZXZEAKYLyGQ== X-Google-Smtp-Source: AGHT+IHMs/wh4/uKU10a6TJOUIK0C/7FJ89YkEUzt2kLv6JiOenStOMG3JLzCl8G4mvnsX/BoqU3yg== X-Received: by 2002:a25:6608:0:b0:dfd:f539:1552 with SMTP id 3f1490d57ef6-e02be10241dmr4964858276.13.1718855985869; Wed, 19 Jun 2024 20:59:45 -0700 (PDT) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-dff44dd4b45sm2067078276.53.2024.06.19.20.59.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jun 2024 20:59:44 -0700 (PDT) Date: Wed, 19 Jun 2024 20:59:30 -0700 (PDT) From: Hugh Dickins To: Andrew Morton cc: Hugh Dickins , Baolin Wang , willy@infradead.org, david@redhat.com, wangkefeng.wang@huawei.com, chrisl@kernel.org, ying.huang@intel.com, 21cnbao@gmail.com, ryan.roberts@arm.com, shy828301@gmail.com, ziy@nvidia.com, ioworker0@gmail.com, da.gomez@samsung.com, p.raghav@samsung.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Bresticker Subject: Re: [PATCH v2 0/9] support large folio swap-out and swap-in for shmem In-Reply-To: <20240619183357.2ee5a818f8de1d4773be2ff6@linux-foundation.org> Message-ID: <5f8a6e2e-8a51-dcad-a8a1-37e44349b716@google.com> References: <20240618130538.ffab3ce1b4e66e3ba095d8cf@linux-foundation.org> <475f0f2c-afc7-4225-809f-93c93f45c830@linux.alibaba.com> <2683b71d-aebd-5527-348c-18c0e021b653@google.com> <20240619183357.2ee5a818f8de1d4773be2ff6@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 163FD1C0007 X-Stat-Signature: u1mfjhu46tp43hmrgejhjyjwrqx6ugu1 X-Rspam-User: X-HE-Tag: 1718855986-776358 X-HE-Meta: U2FsdGVkX1+bH9zX4VDwUuJ46Bl70nGrhuC3LawjWks9ODqNLsyR9C4wPHKTwMo8r5Isb+jFKdtk9cFxd1x9Ws1tUlo3DZjXiYtNBmzM71bpJop+Cf9xp6WJNmabhJGRQNKiSK2Vc71kQGdDRb6OEiSu9Z3mVqlV9E/4SaplLH6yM3Bit2IxliwQJJHBrNuc9oVpl1aLqFq8+SDqizIkXH+ONcYdkgcMm1WRA7DfujFfEYZQZ98lj+hRG6ueA7V9rH9OH73VTaj7Odmz1XL24TTruqwgpURI6W2tTB8KAircIedSG1NuoRFnewlppv1L8krWtky7+HYZieju03C0xnEkfMDNnTIZNpyY9Ai8s7fQyFenF5hhuw5UyEgwGWAwZs9an1iLlzAbmIAYYDz0CZoiEyiW+4lpLqRVQ5ruGBJv3phK7jIkntuT/ktEvwBCSYvNzRqUtgYLVs6asO1qjK4DtuQU97HAqLFNeffYURnmXWJ4z1wdbrt+op1WrcZZYSEI8gmifqiN1W/VC/k3az+5u4jiS5Tx6JwPhQ4ueru/ZF3valaBvBVLM3VAm71dggUE4XXunQ2wIjNhpaELRPO1hOjmctr+sBGgbRQppOWCfbBqxe4F1hIysSdde6ntYOA6PZZcfVeXEOtBefNTf4h9scNU6gEz3b+kDbTXIOE4cU8NraMuUxxbilJOC0P+ig6z6GJ0R/3ya4VO/uIc97j1GucM+Xa0bi+9OdcdOJOXwFvg8XgNgFkQSqedoVf6gfpmcw0OOSAfM9NDhdtgePkD7P4jCoBzfVyS73fa4hHK2ahdx++2ggq+v/SdlFkGahbdlZ0lIkKC1ODL1Z0rgpSC28sm+4XOP/URrg25v4Fycwgk9utiXNP/VjRx9L/9p1vTomssW5PukrBQ2wUe6hMjYT8u0H+dR9hdJJoPomltrsAbwlZFR4WP1h4Bjr9V91bpx75cG9j5ZkLm1VR UDOuSI1o YEmeTmLjJxAwI9Xbl3Yn7hhxewh6aTR28+L99uepRr8m8jHNEO+Xm6BilmuCGF4Ba5hZCGpdYj6UNT3qFZSLCnZbDfHkPA5UHtWacfVzp8Hw/5wT6Q624VrblUz75qgbviPkteWjsaucxU08punST8fPMeLTU3wMC8B2ZzYSVQtWPAfVsSBdiiULSd3PsUve7FLUbK/Jtqpqb+UeyJcdMFXcp/fH1Sbh7vtyqLYJBbf+j9VmoP8cGM0J4esDxDwt9kkFF+vFfdoWKNaB+8A+inV0dtDsx8DDy7q0ny3OJ6I1z++nFt6axQ8pxdVPrcYa/kNpthZixEhFD6CqvRumKk9joUxv0Z2F8Gtm1 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 Wed, 19 Jun 2024, Andrew Morton wrote: > On Wed, 19 Jun 2024 01:16:42 -0700 (PDT) Hugh Dickins wrote: > > On Wed, 19 Jun 2024, Baolin Wang wrote: > > > On 2024/6/19 04:05, Andrew Morton wrote: > > > > On Tue, 18 Jun 2024 14:54:12 +0800 Baolin Wang > > > > wrote: > > > > > > > >> Shmem will support large folio allocation [1] [2] to get a better > > > >> performance, > > > >> however, the memory reclaim still splits the precious large folios when > > > >> trying > > > >> to swap-out shmem, which may lead to the memory fragmentation issue and can > > > >> not > > > >> take advantage of the large folio for shmeme. > > > >> > > > >> Moreover, the swap code already supports for swapping out large folio > > > >> without > > > >> split, and large folio swap-in[3] series is queued into mm-unstable branch. > > > >> Hence this patch set also supports the large folio swap-out and swap-in for > > > >> shmem. > > > > > > > > I'll add this to mm-unstable for some exposure, but I wonder how much > > > > testing it will have recieved by the time the next merge window opens? > > > > > > Thanks Andrew. I am fine with this series going to 6.12 if you are concerned > > > about insufficient testing (and let's also wait for Hugh's comments). Since we > > > (Daniel and I) have some follow-up patches that will rely on this swap series, > > > hope this series can be tested as extensively as possible to ensure its > > > stability in the mm branch. > > > > Thanks for giving it the exposure, Andrew, but please drop it from > > mm-unstable until the next cycle. > > Thanks, dropped. Thanks. I'll add a little more info in other mail, against the further 2024-06-18 problems I reported, but tl;dr is they are still a mystery: I cannot yet say "drop this" or "drop that" or "here's a fix". > > > p.s. I think Andrew Bresticker's do_set_pmd() fix has soaked > > long enough, and deserves promotion to hotfix and Linus soon. > > Oh, OK, done. > > And it's cc:stable. I didn't get any sens of urgency for this one - > what is your thinking here? I thought you were right to add the cc:stable. The current v6.8..v6.10 state does not result in any crashes or warnings, but it totally (well, 511 times out of 512, in some workloads anyway) defeats the purpose of shmem+file huge pages - the kernel is going to all the trouble of trying to allocate those huge pages, but then refuses to map them by PMD unless the fault happens to occur within the first 4096 bytes (talking x86_64). I imagine that this causes a significant performance degradation in some workloads which ask for and are used to getting huge pages there; and they might also exceed their memory quotas, since a page table has to be allocated where a PMD-mapping needs none (anon THPs reserve a page table anyway, to rely on later if splitting, but shmem+file THPs do not). And it's surprising that no tests were reported as failing. I did forget that khugepaged should come along later and fix this up (that used not to be done, but I believe we got it working around v6.6). The tests where I noticed the low ShmemPmdMapped were too quick for khugepaged to fix them: but if you'd prefer to avoid cc:stable, we could say that khugepaged should in due course usually fix the long-running cases, which are the ones most in need of fixing. Hugh