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 9A31DC27C55 for ; Mon, 10 Jun 2024 15:28:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2A54C6B0085; Mon, 10 Jun 2024 11:28:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 254AA6B0098; Mon, 10 Jun 2024 11:28:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F7466B0099; Mon, 10 Jun 2024 11:28:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E67006B0098 for ; Mon, 10 Jun 2024 11:28:42 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 97C3D80FFB for ; Mon, 10 Jun 2024 15:28:42 +0000 (UTC) X-FDA: 82215361284.17.64497FD Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by imf10.hostedemail.com (Postfix) with ESMTP id 87CBEC0015 for ; Mon, 10 Jun 2024 15:28:40 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=SRy8Q1ix; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf10.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.167.180 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718033320; 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=fUARyIEpm9mcxUlH5YwBD2HZnjCRC5iHgPIZ1qpIAq8=; b=6dD9EWfGdXHTWxlVAUU/5QVWzDH6b5aTyePkHG/db2WF2b3VxpIU1S5wCfa8zARYVpYVD+ JIJSzfjfitK79B2c4NVXjJf0UPHDROttSD0+MT0nSFs78DJSnbvShmM0Miwq/fJ7bHKUcz yx9M5ORyA2lSjaZsr7qHRR8kItPZuLM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=SRy8Q1ix; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf10.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.167.180 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718033320; a=rsa-sha256; cv=none; b=FIo7BVW4QxRdcpdU8jF+lenhmMxJvmAECXCa8UrjkMPeppLDMF3B2jq0HvHKmHxV11vTIX a9hKURidFOGGQqTOi5rw05fqGsVJLGxWZ5usIME8rYuM5n6cgLQtLh85hCBH/p36DpToMl 8Rbc2+ym3oCQaHkA5R8NNa9TmbEEpYQ= Received: by mail-oi1-f180.google.com with SMTP id 5614622812f47-3c9b94951cfso2633870b6e.3 for ; Mon, 10 Jun 2024 08:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1718033319; x=1718638119; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=fUARyIEpm9mcxUlH5YwBD2HZnjCRC5iHgPIZ1qpIAq8=; b=SRy8Q1ix8DETDThYTFi0B+A0hHa7RFpvCCnkhwAY7DxWlBas+Qv+1ej+v9z2w5K0B8 4W+JPs1xiOpdAEzoim/czfrIfPtlKrnw2tB+F8M3f+s/+BjWlEwn7wy0vUEmKjcUCOhP wwxpQc+LQEWimKvcMFxCgX6pGBDwCRtJfbYjY83petKFG8zyZoptJnO+qsA1+nHoRmfT ta8nRozMTlJcqCI7kJqMGAvFFT+IE4hzB3Okoj/SceKcQqyqltgEmooUtKfNyW17FLn7 EPj2uKhs7zzOIC1gR6c6LzrkfM2kzDwlMfQpJUWuOETmn4XVzcDY4ZnAUn4vzWbxLbte wo2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718033319; x=1718638119; h=in-reply-to:content-transfer-encoding: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=fUARyIEpm9mcxUlH5YwBD2HZnjCRC5iHgPIZ1qpIAq8=; b=pM85j/2s3QRNUr8qELwzj/gm2dZsPmKgmgEdzqRCt4OJHNmTjYNc8w0YDihsDOBJJL mEqTRbymIq0D2CXfKyfaHI99m+QSJN+CVDj86rQII1pK/WkNuJD7rh8j3hTboHRBip2z RtneS5L1MVKrOD4S2cS9mVACP4RE03gY1Dw5MxDV5G5yuxbKzfexZJu0WIpw5SkMq7GC OwTPKWPKw2NUpu4Qwb9WZNk1k7CzbzSqzjyKdFmSqy0smGZSscaU1Ycl2AkKbKXz0+H2 pGY684+/kDuE+dYy9CdBWm2Brw6fM1mDCRVTX6V+3EcoXFrLsYsXQNBi/dCeQlGu1YUV D+DA== X-Forwarded-Encrypted: i=1; AJvYcCVy7+e5pLaWz3WtPJU9zaZKRPlEGa8fXKBqCUDEGi9VuegIgz8IAqGd9xKvBXFhJuAgBvYJvkdoyVBmEqolnmemMQQ= X-Gm-Message-State: AOJu0YyoN+Flcf4TenjB8ORZCvmPg3ftJvdGQLwIBTw8N6NFY42R4MtD J0FQbY80UpalAZ0eKXu7+nlquEVvkYd3RpMlEHqvGI8Z1mNBkQQZBpsoLwn5LwA= X-Google-Smtp-Source: AGHT+IFyT07TFV5Ytc4/MXNzKU3Je9EmZJpvpo4etZVRacJKdSABCIQxDVPoD1j3wxRiIfTWjsN/nQ== X-Received: by 2002:a05:6808:1596:b0:3c9:6e55:e24c with SMTP id 5614622812f47-3d210d27ed6mr12167562b6e.11.1718033319250; Mon, 10 Jun 2024 08:28:39 -0700 (PDT) Received: from localhost ([2603:7000:c01:2716:da5e:d3ff:fee7:26e7]) by smtp.gmail.com with ESMTPSA id af79cd13be357-79557127817sm210991185a.40.2024.06.10.08.28.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jun 2024 08:28:38 -0700 (PDT) Date: Mon, 10 Jun 2024 11:28:33 -0400 From: Johannes Weiner To: Yu Zhao Cc: Andrew Morton , Vlastimil Babka , Mel Gorman , Zi Yan , "Huang, Ying" , David Hildenbrand , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Kalesh Singh , Chun-Tse Shao Subject: Re: [PATCH V4 00/10] mm: page_alloc: freelist migratetype hygiene Message-ID: <20240610152833.GA2298848@cmpxchg.org> References: <20240320180429.678181-1-hannes@cmpxchg.org> <20240513160331.GA320190@cmpxchg.org> <20240513190400.GA2270702@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 87CBEC0015 X-Stat-Signature: hczx8jgohhpaq991ircyjmtiz1rgtgpn X-HE-Tag: 1718033320-450336 X-HE-Meta: U2FsdGVkX1+/HewgiZP1LOI71twZyJPlE4maopwlkt6FHf1zD0cw5g78DNCL2BBM6iDUQGz2rsmNJMTYXYaZK4ewDlr+RyOpg96UXVK+7za6h5udEaZR5oSnwyPa5idyMokLxHxTt0y2gE9TlbqoabItfW4haoetpr0hI075gvOGRLjjDwNZ9C/ejcQOTu9WhxerkxAP/e4KMlJXkJIiYVxT6PMStxj4aBnDjZkWh2r0ATwn6N7XFHOk/puU8JMTMn32V8Y7oVyLDigpK/lRgWAr9feXSNidq/H5wvTnnz50cYTowAlybqPlWTbejChJxT5G9zZBHpG1cjiDI/S2+jD0BnDIzAMdZ3W2JbIXoVPWmcX31IsOgN/TZ22UVj8ApJStdYrOIJ0C+lQpyJUJuEJNPkYmwYjTufUlXVOZzESWTlTQ8MBtLTRoyszHFOtJn9/Zx+q6Q147JTWVJb0eCO27IzU3s0j0dRHMm9cob/mNBbPmIQlbBqoitVB2z70A0aBqHWJ1HySIltnLEZA00rrj754hFww0xx4SFFDcb4D5opQhjntTATv4MBeJCJC/FYfY9PDWhGOsqGFYc91Gr0wR9HkBK/RJVr3I0gF2l7UpYQKqm2UtePAEkextfFxrkHtzpCpBadv5XpPGchh9a5ZylqHXgF65Wx9I7++JyuFtm9Eh079BZ79jDSDWna5ya34AYMGmN0pc5oZZIfSvbNtgO61m1h0QFhH9J5Eeqi5cCKyu+S5qrjkXxw6Ca+8efyUduB6iJ4bBZf1kICens00dP+WvgqRja8DvAoQPLUAQXfLEbg+3nEyPgwzyAcUERtwmwiSyUITU+aK9m7wSalQfgozrFBu7yzfZLlGsQCDoi6hY3+OqK+KHsVrQ3WsC6hKNZJY2yFiM6O0Y2OzljKfDDDCYVJTduW6CL9yjhLUGxn5eNxl9S+pLX3d1XSQEDuwz3DvPsaCU3GdjcH2 iUH9U5Lm atu6Bc/buNGP/Rr2h5T4ev3LV3A7/N21JCp/SHD8vyYrmt0j+ZrCM55rl0wujbC904KhxUtGx0V4AVrT1eaMFDmgDeyGSv53I9RbqBKp7kIaoRLF4Vxow8d8Y1BrzH9NGnZ5oc8TbgvoOUvarAvP166f9WD6Yp2+umo00IFURLx+2+sjnySulsKp+6bJBNDlHkh2ZnTlSLTa8IBJox3WuAo+sjmzigCbLWtD06hsq+MuuwR4xZ2ggSl6hpGxwZCAghic+YdDIhDnnAoNzaX8XVYWGTTUUp67fnM12XqHOWroAbzD5fTeymQFafsUHffLNiLxWdoeC4eCxYQT3Rlgj4z5H/vG9IOTzvtpVj5vuLxJUMBLW2uNqayr5FR5oY9UasBEop4VAXlAJKqN0WieN8xdazNaXRXlmJtINj1JTWfxS17CNCtLzZBctOoZeFLrL/INxcOSQZJ8EE27/2YT/jel9Z3fb6rhQn6Hsru4KLdqYNNo+bqQPl0d7/jOKydbvd/4XCYb0/5kgwGRuWcg+d3o+XuKCFk8WtoIVRTQBggpQybmKOb+9luUFugRQxGl2/VkOqYoNARZyvqSYUxG6OqcYtA== 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 Tue, Jun 04, 2024 at 10:53:55PM -0600, Yu Zhao wrote: > On Mon, May 13, 2024 at 1:04 PM Johannes Weiner wrote: > > On Mon, May 13, 2024 at 12:10:04PM -0600, Yu Zhao wrote: > > > On Mon, May 13, 2024 at 10:03 AM Johannes Weiner wrote: > > > > On Fri, May 10, 2024 at 11:14:43PM -0600, Yu Zhao wrote: > > > > > This series significantly regresses Android and ChromeOS under memory > > > > > pressure. THPs are virtually nonexistent on client devices, and IIRC, > > > > > it was mentioned in the early discussions that potential regressions > > > > > for such a case are somewhat expected? > > > > > > > > This is not expected for the 10 patches here. You might be referring > > > > to the discussion around the huge page allocator series, which had > > > > fallback restrictions and many changes to reclaim and compaction. > > > > > > Right, now I remember. > > > > > > > > On Android (ARMv8.2), app launch time regressed by about 7%; On > > > > > ChromeOS (Intel ADL), tab switch time regressed by about 8%. Also PSI > > > > > (full and some) on both platforms increased by over 20%. I could post > > > > > the details of the benchmarks and the metrics they measure, but I > > > > > doubt they would mean much to you. I did ask our test teams to save > > > > > extra kernel logs that might be more helpful, and I could forward them > > > > > to you. > > > > > > > > If the issue persists with the latest patches in -mm, a kernel config > > > > and snapshots of /proc/vmstat, /proc/pagetypeinfo, /proc/zoneinfo > > > > before/during/after the problematic behavior would be very helpful. > > > > > > Assuming all the fixes were included, do you want the logs from 6.8? > > > We have them available now. > > > > Yes, that would be helpful. > > > > If you have them, it would also be quite useful to have the vmstat > > before-after-test delta from a good kernel, for baseline comparison. > > Sorry for taking this long -- I wanted to see if the regression is > still reproducible on v6.9. > > Apparently we got the similar results on v6.9 with the following > patches cherry-picked cleanly from v6.10-rc1: > > 1 mm: page_alloc: remove pcppage migratetype caching > 2 mm: page_alloc: optimize free_unref_folios() > 3 mm: page_alloc: fix up block types when merging compatible blocks > 4 mm: page_alloc: move free pages when converting block during isolation > 5 mm: page_alloc: fix move_freepages_block() range error > 6 mm: page_alloc: fix freelist movement during block conversion > 7 mm: page_alloc: close migratetype race between freeing and stealing > 8 mm: page_alloc: set migratetype inside move_freepages() > 9 mm: page_isolation: prepare for hygienic freelists > 10 mm: page_alloc: consolidate free page accounting > 11 mm: page_alloc: change move_freepages() to __move_freepages_block() > 12 mm: page_alloc: batch vmstat updates in expand() > > Unfortunately I just realized that that automated benchmark didn't > collect the kernel stats before it starts (since it always starts on a > freshly booted device). While this is being fixed, I'm attaching the > kernel stats collected after the benchmark finished. I grabbed 10 runs > for each (baseline/patched), and if you need more, please let me know. > (And we should have the stats before the benchmark soon.) Thanks for grabbing these, and sorry about the delay, I was traveling last week. You mentioned "THPs are virtually non-existant". But the workload doesn't seem to allocate anon THPs at all. For file THP, the patched kernel's median for allocation success is 90% of baseline, but the inter-run min/max deviation from the median in baseline is 85%/108% and in patched and 85%/112% in patched, so this is quite noisy. Was that initial comment regarding a different workload? This other data point has me stumped. Comparing medians, there is a 1.5% reduction in anon refaults and a 4.8% increase in file refaults. And indeed, there is more files and less anon being scanned. I think this could explain the PSI delta, since AFAIK you have zram or zswap, and anon decompression loads are cheaper than filesystem IO. The above patches don't do anything that directly influences the anon-file reclaim balance. However, if file THPs fall back to 4k file pages more, that *might* be able to explain a shift in reclaim balance, if some hot subpages in those THPs were protecting colder subpages from being reclaimed and refaulting. In that case, the root cause would still be a simple THP success rate regression. To confirm this theory, could you run the baseline and the patched sets both with THP disabled entirely? Can you elaborate more on what the workload is doing exactly? What are the parameters of the test machine (CPUs, memory size)? It'd be helpful if I could reproduce this locally as well.