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 A3A5DC54ECC for ; Wed, 28 Aug 2024 10:45:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 320A86B0088; Wed, 28 Aug 2024 06:45:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D05E6B0089; Wed, 28 Aug 2024 06:45:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1989A6B008A; Wed, 28 Aug 2024 06:45:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id EDB206B0088 for ; Wed, 28 Aug 2024 06:44:59 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 999C3141EE8 for ; Wed, 28 Aug 2024 10:44:59 +0000 (UTC) X-FDA: 82501321518.23.885CEA2 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf26.hostedemail.com (Postfix) with ESMTP id 8DCF014001B for ; Wed, 28 Aug 2024 10:44:57 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QTXci9cV; spf=pass (imf26.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=usamaarif642@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=1724841828; 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=x2kNJxOTuqFsipbBScG0DLZ5hyvlGOCflIXITsRjahw=; b=tAKkS2a+rQRf4dFm8z4IDEm88t904mgWNS+YsZo3pyVHjLdqA0dw/qigQfFnfH1Sy34Lca BMcQGKpLOp4CgQdyScNxm5ObGMmPpsaiZYPCEXkm+P/rSWZmT9SWy4lwsHApEQQ9IwmZt7 PgbpHN9ShcZGh6B2H7O0Q0QEpa2lhZs= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QTXci9cV; spf=pass (imf26.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724841828; a=rsa-sha256; cv=none; b=t5MueZJ0WAtEcxo2IuV7trbTDQ9V8TsbBDScQxbUJ0XJjmQdqkB8QolBLt289T9oM/vUzj x+5wuck/QG6S0rkftWJikErGTVsPjiPQr1cTXPYOr6zywVaKLgP4QD6SPF0egVkRVmYrz3 KbQWEphDkAAVI3xQghvzupZ8f+CIQks= Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a7a9cf7d3f3so826202066b.1 for ; Wed, 28 Aug 2024 03:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724841896; x=1725446696; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=x2kNJxOTuqFsipbBScG0DLZ5hyvlGOCflIXITsRjahw=; b=QTXci9cVZSlLZg1VepFPQteZ/pOdEfeRr+Cgv2nhjCnwlVMrM4hHLEl+5DlUIDJo2N 32vZ4CfmPhUw0xMr5EjR59I/gJXjksGoBfM/E4Kqyk7PdSf+EH+30uDYmLTfPAQBTp48 lU8I93Z8oWAP1GNSnpfgc0tWjNNukz4s6dqHd7cHPHqT/eNv229h1geu7mSaRkt4Z16N 0a9WtYReFLv1ZYmYimhrVLZO9lSnInBek1+jgJjvkvRZmotFElqR1TcNpXg5QAl3KuyK nJFBgrXLfqj/drX514+REMCc4dVFqg+OmP2g22jQqPbVQQSMyNdwDiSWwIRnKGUW6nOt OuzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724841896; x=1725446696; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=x2kNJxOTuqFsipbBScG0DLZ5hyvlGOCflIXITsRjahw=; b=M7UjkB0Y5wRag7IuPIm05wrwBlHXSpGRp5UFw9aEbgSQqbJOsigWmwNW3uqn6Ch4Va ZO8ZlnLnpZF2oHdE8/rC1AIIIP17omLzd9DvPqck2L+lUs4Phy6o5adafpBQMNRHGqzr fRDhOnm3hrBOkvLA8ohosnFsW4t4fYHAWgCQ+127L2yNp3cihyOH8Pj+5uRTRZMAG09g 9f/DW3XotOazjMwjTWaOXXpnFJBM9RrKI6moY91+8DWEiliikw/lvfVM8MDwLCMpAxxh cbYL7QOV/cbl0FWJaLyXnXkr1WpF74pwThVHk0NM+LAHGPO8qp2xrNOtpMo8IylEA7mv 12RA== X-Forwarded-Encrypted: i=1; AJvYcCUjsUw2MN9KRtSFz4xJuBpmqrSEYwVR7nCFUAJLRQE0JzvkF0deEvPTuVCxXtm2C3WHbkjGGCaV6g==@kvack.org X-Gm-Message-State: AOJu0YxCEJ2irY1snqSMsA2jqFt8NF0Cd5HRGlinpLIdCp8dq89xb7jf BVW4utE1KZn1uV8PwVZ39M2TVyfMWSt7gIZ3e6Y+OuDhnilqWaJU X-Google-Smtp-Source: AGHT+IGMoYDTVcLmKtKBbEfgOB2rQ1TYZVKs5frEt7O1bdUKTrEU6PFwVisPNEMHr/crvWP4yyLLHQ== X-Received: by 2002:a17:907:2d8e:b0:a86:83f9:bc1f with SMTP id a640c23a62f3a-a86a54de2cdmr1014126366b.61.1724841895200; Wed, 28 Aug 2024 03:44:55 -0700 (PDT) Received: from ?IPV6:2a03:83e0:1126:4:eb:d0d0:c7fd:c82c? ([2620:10d:c092:500::6:b05d]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a86e58315dbsm228435366b.106.2024.08.28.03.44.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Aug 2024 03:44:54 -0700 (PDT) Message-ID: <18647b68-0c7c-47bc-9b9e-9cf46ce86761@gmail.com> Date: Wed, 28 Aug 2024 11:44:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 0/2] mm: introduce THP deferred setting To: "Kirill A . Shutemov" , Rik van Riel , Nico Pache Cc: Johannes Weiner , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Andrew Morton , David Hildenbrand , Matthew Wilcox , Barry Song , Ryan Roberts , Baolin Wang , Lance Yang , Peter Xu , Rafael Aquini , Andrea Arcangeli , Jonathan Corbet , Zi Yan References: <20240729222727.64319-1-npache@redhat.com> <72320F9D-9B6A-4ABA-9B18-E59B8382A262@nvidia.com> <61411216-d196-42de-aa64-12bd28aef44f@gmail.com> <698ea52e-db99-4d21-9984-ad07038d4068@gmail.com> <20240827110959.GA438928@cmpxchg.org> <9cf237df1a7bb21bba1a464787938eba8f372658.camel@surriel.com> Content-Language: en-US From: Usama Arif In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: ag5a1gsrgfgrm6mmksdk1cmrdihwkdr8 X-Rspam-User: X-Rspamd-Queue-Id: 8DCF014001B X-Rspamd-Server: rspam02 X-HE-Tag: 1724841897-99837 X-HE-Meta: U2FsdGVkX1/bGdG0QD41+y4Z4SeNEuJXPnolAgoZtUVIVc4qBrK0XAqDcPrOUAe17ewkZEZ7GL+uMUCkR6nidN8csnZMETvxWBMnoHm6nukVRdrcb3Yok02X+jIlz5bPspsgtVD4H2oAk60njVCo5mysLXxbGWVPbnD+AtoiGUQbeJ6VgFWjQleqSXO11Ua26S2TmrFzN7Ljn5gOT1YHZFlhbCQBY5cKGicuECw//0ttPyMjq8WroKuKUekxWmsBN7BiIjjtaTSUd5iLBKUO6ssomm4kBURHupyn9vCT31tFUdmBixYixtTd2J0M27521xoloH4eI3ak5HBm3Wifxt87LByciGkuoYpKuqFJt0EAc2Kc1mY6mcB+hkdIqNpSXGe/G3S6XAPH5NndvX+QrGMIEzJuoAIirTMebhjMAcg2/Zu1M8CftrmV+Dw0Ih3ApOB9qcJsnhuTjD39Xj0e4n9+tlocHl1vOV7YKO8YQtx0DDFrbTPMfK7G1cTPys+BRt7gQEa5Faq262i3vrIle47KZI5RCmQDsUZjQfGTapgfdX7VnKDkD0CtemWh30KYuf6vgNODEGpq0Tfe0FlPEHxHYpPS+f6luXcVe1aIasBLQUNHKTzxXmozNZ90X6yr2q0BIeOQ0oypem/GtkEy8Qj5zHSkRG97Ss5VH1PrkV8z2rSP5dYJ8G6UWVpFf96oogV9mIB2BIaXLjvVP68w0VH2C3n2txwUaeJlizg8Ryl9+g0ZyoQOFrG/yp7cw9YorCgB0WPmm3JEgq+4VxTbDLPlLpa4dRuWO0Lr3MiVp0sO4lV6Qa3FDFRCivtmFQSug9c2gy0I0utX/HROpnmrgI7FlbTTSBvObQcseA05QRQb64hUElYcDhPt5EvVDAPlSCJ3dHw69E1IJKeL6g9EnAHGHHpZ1FTHpHxx6aB2iI1ySI2AmjY0qe0uDKKJf18dSibOFyJ8NqR/k/7UgmS NxuiAS8n 8Oa+rszy5GCJuTg0jTTv9r8aQaTa2a+SNts6bCaWz+1DAqAUbefNUPq7SccqAiJ3EL1LLZQEonxbnjqRVfxzxCSrd1l8tpzrh1x2XpBn7fjfUHgTyha22hplqD+Mv3WIbcKB2ifF7n8Sj8k2/esz60HyR673+rUi4ZrSJgglACmfX9vLD1miy2W1sGvV79pecWd8Qz1aiCTqlyZCsQfrfiYLMS033IITmZXV3n/gTCqcHIBnjuB1MMYNieKAwzz1vghhLBTszGBXWFbFq3jXWUX1yptroGKKoVVjPEzi/gSG78GoJ0BrauTvqRAfhFMYBDQf4snn1avPV27nsVCEci5Bx8LA2qruTaGNmHktdypxMrdKrKdWIiWCEARcvgLXnQRZ7xL2fPbXSzMl736KO5PfUB8toM+l7yvx6g5R0xau7E5t/j7KZ0XoHMFQxtKllDRgkAsobG8Pz3iGWHMqMMLvA4sku3ooiIpacUQbnvIqePMZenQQMLcgWizlsP0I4LpOQdeRFiQ2BcU0= 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 28/08/2024 02:17, Kirill A . Shutemov wrote: > On Tue, Aug 27, 2024 at 09:18:58PM -0400, Rik van Riel wrote: >> On Tue, 2024-08-27 at 13:09 +0200, Johannes Weiner wrote: >>> >>> I agree with this. The defer mode is an improvement over the upstream >>> status quo, no doubt. However, both defer mode and the shrinker solve >>> the issue of memory waste under pressure, while the shrinker permits >>> more desirable behavior when memory is abundant. >>> >>> So my take is that the shrinker is the way to go, and I don't see a >>> bonafide usecase for defer mode that the shrinker couldn't cover. >>> >>> >> I would like to take one step back, and think about what some real >> world workloads might want as a tunable for THP. >> >> Workload owners are going to have a real problem trying to figure >> out what the best value of max_ptes_none should be for their >> workloads. >> Yes, I agree. For both solutions, max_ptes_none needs to be adjusted, and would require experimentation with different values which workload owners might not do or want to do. But as Kirill said, the information on the number of zero pages in THPs isn't available. A possible solution might be randomly sampling a number of THPs at certain time intervals, but I don't think its a good idea to use that as a representation of the entire system. Its ok from my side to have both the solutions in kernel as they don't interfere with each other. THP=defer makes sense to have as well if there are real world workloads or benchmarks that show page fault latency is problem due to THP=always as Nico mentioned in his reply [1] [1] https://lore.kernel.org/all/CAA1CXcCyRd+qfszM4GGvKqW=95AV9v8LG5oihByEBGLtW4tD4g@mail.gmail.com/ >> However, giving workload owners the ability to say "this workload >> should not waste more than 1GB of memory on zero pages inside THPs", >> or 500MB, or 4GB or whatever, would then allow the kernel to >> automatically adjust the max_ptes_none threshold. > > The problem is that we don't have and cannot have the info on zero pages > inside THPs readily available. It requires memory scanning which is > prohibitively expensive if we want the info to be somewhat up-to-date. > > We don't have enough input from HW on the access pattern. It would be nice > to decouple A/D bit (or maybe just A) from page table structure and get > higher resolution on the access pattern for THPs. > > I tried to talk to HW folk, but it went nowhere. Maybe if there would be a > customer demand... Just saying... >