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 17C59C02182 for ; Thu, 23 Jan 2025 20:42:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6BDCF28000B; Thu, 23 Jan 2025 15:42:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 66D5E6B00B8; Thu, 23 Jan 2025 15:42:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50E5128000B; Thu, 23 Jan 2025 15:42:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2C68F6B0088 for ; Thu, 23 Jan 2025 15:42:41 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B1A11AEF73 for ; Thu, 23 Jan 2025 20:42:40 +0000 (UTC) X-FDA: 83039890080.09.F150A7F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf06.hostedemail.com (Postfix) with ESMTP id EB40A18000B for ; Thu, 23 Jan 2025 20:42:36 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Utn25dsl; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf06.hostedemail.com: domain of npache@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=npache@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737664957; a=rsa-sha256; cv=none; b=g7vDQpwvz2NlxNfWk204QnOxYOL1JrPeijgSRgESMi7eEghB2SAFRfye8frVjVI8GLluK4 qGmND8GQF3kRIXc9+ycvpMP7lp/XohV2yaOcWO4kjhK9GwrCXR5HJnHG5caML3t3OHHvVv M1H0SiGooc38DWXRAVq3OaEtQgkXwyw= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Utn25dsl; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf06.hostedemail.com: domain of npache@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=npache@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737664957; 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=55KVsli1VllkBrSmzOX7Ue0sC3+NTaJdFYpuWmgdzEs=; b=8KR2aiWbLtRSslIXIPRE2T/0BVkx5a4Nn5ue9a4CIkULsf0pR/7ANK6YKPMLd85qzcYGWM QqulzqVU6FfzESRwQFseWFK9NKxtZDWU2SiEaECIGJXWqZVEoWAjTnowmI0kwTu4F7age5 XONU39O4RdFmV9MMEzCqiQzIzIeZC1c= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737664956; h=from:from: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; bh=55KVsli1VllkBrSmzOX7Ue0sC3+NTaJdFYpuWmgdzEs=; b=Utn25dslE6Uo8R1/dNWf8Bmx+U8ll/qXpHhAlWv2jD2ymK3GPeaS3x5PWq4OofFnsT7+Tk 1VCkFCWBxwoCZRT6/hiiSqa4m6IFp54nfpD9HWP7x4BViuoJha0Gl54Fjsqrm0TM+DN18d 8FYHjA+hr3b6VMHQobLEN7ehKsARkzE= Received: from mail-yb1-f200.google.com (mail-yb1-f200.google.com [209.85.219.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-357-KSgJ98H8NLSNihhoIp9NRA-1; Thu, 23 Jan 2025 15:42:35 -0500 X-MC-Unique: KSgJ98H8NLSNihhoIp9NRA-1 X-Mimecast-MFC-AGG-ID: KSgJ98H8NLSNihhoIp9NRA Received: by mail-yb1-f200.google.com with SMTP id 3f1490d57ef6-e583e39f618so148178276.0 for ; Thu, 23 Jan 2025 12:42:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737664954; x=1738269754; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=55KVsli1VllkBrSmzOX7Ue0sC3+NTaJdFYpuWmgdzEs=; b=i8hhrOXDCO5AzGDxdAO2t+tJ9DbmNpiXb3uwZEeD2Yx6bkBLpB3lTt6CXvit20YBax vhr2GidQFRS0v0TPHxbiviW6BwlTSoJUwQ64nduI/mSFeWuYiR4qC3SfOZNFqAGVCjYS hgv0LdubJ38CejtC/oalZGhMZjIDI/QMjI6vmI40++z3R15VIJvZq0lNWQD+4hxT8hUg 3JiZ4JHw4OM8AkRSwA6aGnfXabJ4Wi/wT2gXe5qpkbVzh4yY3pzLwiCxJ0eEgEcMCtjt ghDAh91FwsNIoes6D0Yla7SYbvEAyScRZKbnaS/byw5eSS7y3PZ/zY/OeLxg7SUO1phP UmzQ== X-Forwarded-Encrypted: i=1; AJvYcCXVlMKGIixE88DEGDmU3+DJffmOAQrdGPyPYN5XPizctjCrjbDHTX4/VBlpj3LYW4ix9ak3LqyiAg==@kvack.org X-Gm-Message-State: AOJu0Yw6TTwLb9m5JIz3lYwOhbnTv97PYxABUOr6L08Q+Sfrl4O+ovY6 6/rTdqp0DChPAk2e4yLBymxMTs9to0EON7in1vz1sSrbFPas7cd+U2VGsFw9XIgZuTSGzWU5rbX 20EgXNMGwNGZLNn7F2qyO6RnFxh1B49+NQlh66wchtlq4hA1n3OQgYy3RMxqX5B0ooRguJ2nQjY VbM7GU/BuazzWBXx32Q6AhwjU= X-Gm-Gg: ASbGncsNUfc/ERJ+9Qg9yU9SPRnlaEu+YChnro7wWi89v8xtI1QXquesE180eFLQbPN HqinquhYgCE3Q8KiUUmN/iU7wxNTSDebq7CAzEmdxpAfeRLiu6Foxp7eXY045EMgtvA== X-Received: by 2002:a05:6902:1b82:b0:e58:1112:c3e6 with SMTP id 3f1490d57ef6-e581112c874mr8593349276.2.1737664954243; Thu, 23 Jan 2025 12:42:34 -0800 (PST) X-Google-Smtp-Source: AGHT+IHfoajcIJoniHSLvlPy7a7fkD63RwDhoBSgOmUPy0AQDx0prtY41BMBEjzc5Mx9DoMeLBc94pbjbJm2rKc/St4= X-Received: by 2002:a05:6902:1b82:b0:e58:1112:c3e6 with SMTP id 3f1490d57ef6-e581112c874mr8593326276.2.1737664953858; Thu, 23 Jan 2025 12:42:33 -0800 (PST) MIME-Version: 1.0 References: <20250108233128.14484-1-npache@redhat.com> <40a65c5e-af98-45f9-a254-7e054b44dc95@arm.com> <642ade70-b671-4f03-9ea3-7b836f3aebf9@arm.com> In-Reply-To: <642ade70-b671-4f03-9ea3-7b836f3aebf9@arm.com> From: Nico Pache Date: Thu, 23 Jan 2025 13:42:08 -0700 X-Gm-Features: AbW1kvZNz65B9cpOxZHJKlBuVQ7TCruY4QWeoLEb7G_g73itzLaDrBADZXYmCXs Message-ID: Subject: Re: [RFC 00/11] khugepaged: mTHP support To: Ryan Roberts Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, anshuman.khandual@arm.com, catalin.marinas@arm.com, cl@gentwo.org, vbabka@suse.cz, mhocko@suse.com, apopple@nvidia.com, dave.hansen@linux.intel.com, will@kernel.org, baohua@kernel.org, jack@suse.cz, srivatsa@csail.mit.edu, haowenchao22@gmail.com, hughd@google.com, aneesh.kumar@kernel.org, yang@os.amperecomputing.com, peterx@redhat.com, ioworker0@gmail.com, wangkefeng.wang@huawei.com, ziy@nvidia.com, jglisse@google.com, surenb@google.com, vishal.moola@gmail.com, zokeefe@google.com, zhengqi.arch@bytedance.com, jhubbard@nvidia.com, 21cnbao@gmail.com, willy@infradead.org, kirill.shutemov@linux.intel.com, david@redhat.com, aarcange@redhat.com, raquini@redhat.com, dev.jain@arm.com, sunnanyong@huawei.com, usamaarif642@gmail.com, audra@redhat.com, akpm@linux-foundation.org X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ml3llL_MbnZ9Rj1Tk9TYW_DYxu4OjvFMPJAo5ekFUW4_1737664954 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: EB40A18000B X-Stat-Signature: z3gyb5hj6kncwps5h6zyciudrm3b88yh X-Rspam-User: X-HE-Tag: 1737664956-928115 X-HE-Meta: U2FsdGVkX1+0+XoFqyIsP0HhtnhmRQSezCrvXWPKCZ1UT+YGIASc3dbq0TSbxReo4G85x8EvMzUTCfWtEff72bN0x/7EaPUJJ/DE2R58BdhgoVutEx1aemiKQl61TjGeSUcIBFhvVwi6tZ1LOjwOZTzodv74EtM/b4eU6xwh/QlXdcZbUxt18ZKixo/KqEbbqXslD6VlVEdTB92xG+o+QGzflx5ETVoMP+DljZYAhv/BWFcKNGOokpEaDb3h23CTDKocGHfD8fgQHes5C9FXNQJNXkRB6CKArfIPaueVBCo1o4gGOaPn1oTl8m82NQVmAuGgdWgsxYg8eqIznOLE8YRoQ+lzowf2C71bDPqpEuW9EGMgp/4V5AWGpDJRDQj8DoQS/YhezDGDBunyNc6SPvNYjJarn0IKVP2PZ8XEYfsVFopFn/hUWgZA/cHxeq4jiKeuoR2i9LaYFGkjzy/8xIEdOsCx0a9cnUi0Iopm9tEeV2BgDEASxkOzhPcnnIgdNI6SN1I/d2svUZ5oJp/X01eipNDGhF/gEiatHfuq8xCmdcaOUfuqd514KPh5V+wY3FjVqPvSgZYiAvTf/UadIQscht7WeJojyXJ81JsUNZ3Zwz/lz5/JNI+PGLORIf6/3wN7or607QXdN+JnArtJXAM3sD8UXmoAfgBLNO6fAxc6p6rV19baH1SSLpNQWMOUh4TesSqZX9KceauuEOV+3zok5UB3P8VS4r9niBrfLaC6NSeM+jUkQi+kfrVkqWdm/aXp1VVmNPrE5Jk2b+00EBflCDOUDBgpXsddXEaNiU+MVj+4uSkzjudqAc54chTdMyKHxyTTiRhB6pFkoa7gxluxfWni3mmmYDBvuNwqURHjMPBrnYtfB3MubnbHQGcfbzLjIWhZxhUgZbEvSJN08e2UPKygSeu67diDtcrLG9hUWNXiYngxtzhLuxwlFzbXCJctDfFsX73qBVIIlvA a+0u1JVz GP2ffPuNAAmFmxoxhaaL1vdJuk0GFkP9TFElLebzt4wKS5i8dwwc/Gwx3lk+hOr14R3WUevKloEeqKXBiXvWDVo24unm4osxbrbGhM2bbtpiDjiidGGT4rbQi3VHUkbw6uyK+RAICSP0+vIwZRvVE5ZVxOrw75zWkc/GRFM6lJ05a1sIdq1IsOelpOoo7YyC7w0fx8B/5t2WJ0OSua1KRj7G0v0MNuH91Mc9M0mjNQNLXV3hkzNYmAguEeRCjz41NngB2xSSDsX9UtFJMluumR8HUnosCY0h9O7yqoWHw9i68HALOpCfOilnxJ9m8oAR/vuGh+wWmsh/924sbB9eNaYefhwzWh2uk/PiRNZtW4Sn/I8mDs8e5IfA8zk/Yljz/q/JPpaIZ0l6QoDg8nitMX00vjw== 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 Mon, Jan 20, 2025 at 5:49=E2=80=AFAM Ryan Roberts = wrote: > > On 16/01/2025 20:53, Nico Pache wrote: > > On Thu, Jan 16, 2025 at 2:47=E2=80=AFAM Ryan Roberts wrote: > >> > >> Hi Nico, > > Hi Ryan! > >> > >> On 08/01/2025 23:31, Nico Pache wrote: > >>> The following series provides khugepaged and madvise collapse with th= e > >>> capability to collapse regions to mTHPs. > >> > >> It's great to see multiple solutions for this feature being posted; I = guess that > >> leaves us with the luxurious problem of figuring out an uber-patchset = that > >> incorporates the best of both? :) > > I guess so! My motivation for developing this was inspired by my > > 'defer' RFC. Which can't really live without khugepaged having mTHP > > support (ie having 32k mTHP=3D always and global=3Ddefer doesnt make > > sense). > > I'm not sure why that wouldn't make sense? setting global=3Ddefer would o= nly be > picked up for a given size that sets "inherit". So "32k=3Dalways, 2m=3Din= herit, > global=3Ddefer" is the same as "32k=3Dalways, 2m=3Ddefer"; which means yo= u would try > to allocate 32K directly in the fault handler and defer collapse to 2m to > khugepaged. I guess where it would get difficult is if you set a size les= s than > PMD-size to defer; at the moment khugepaged can't actually do that; it wo= uld > just end up collapsing to 2M? Anyway, I'm rambling... I get your point. Yeah looks like you found one of the issues. so defer means no pf time (m)THPs. mthp sysctls need a "defer" entry, what does it mean to defer globally and have a mthp size as always or inherit? I assume for global=3Ddefer and mthps=3Dalways/inherit/defer, we defer at pf time and can collapse the mthp. and gobal=3Dalways and mthp=3Ddefer, we always allocate a thp, then khugepaged can scan for (m)thp collapse. > > >> > >> I haven't had a chance to review your series in detail yet, but have a= few > >> questions below that will help me understand the key differences betwe= en your > >> series and Dev's. > >> > >>> > >>> To achieve this we generalize the khugepaged functions to no longer d= epend > >>> on PMD_ORDER. Then during the PMD scan, we keep track of chunks of pa= ges > >>> (defined by MTHP_MIN_ORDER) that are fully utilized. This info is tra= cked > >>> using a bitmap. After the PMD scan is done, we do binary recursion on= the > >>> bitmap to find the optimal mTHP sizes for the PMD range. The restrict= ion > >>> on max_ptes_none is removed during the scan, to make sure we account = for > >>> the whole PMD range. max_ptes_none is mapped to a 0-100 range to > >>> determine how full a mTHP order needs to be before collapsing it. > >>> > >>> Some design choices to note: > >>> - bitmap structures are allocated dynamically because on some arch's > >>> (like PowerPC) the value of MTHP_BITMAP_SIZE cannot be computed a= t > >>> compile time leading to warnings. > >> > >> We have MAX_PTRS_PER_PTE and friends though, which are worst case and = compile > >> time. Could these help avoid the dynamic allocation? > >> > >> MAX_PMD_ORDER =3D ilog2(MAX_PTRS_PER_PTE * PAGE_SIZE) > > is the MAX_PMD_ORDER =3D PMD_ORDER? if not this might introduce weird > > edge cases where PMD_ORDER < MAX_PMD_ORDER. > > No, MAX_PMD_ORDER becomes the largest order that could be configured at b= oot. > PMD_ORDER is what is actually configured at boot. My understanding was th= at you > were dynamically allocating your bitmap based on the runtime value of PMD= _ORDER? > I was just suggesting that you could allocate it statically (on stack or > whatever) based on MAX_PMD_ORDER, for the worst-case requirement and only > actually use the portion required by the runtime PMD_ORDER value. It avoi= ds the > kmalloc call. I originally had this on the stack, but the PMD_ORDER gave me trouble for ppc. Ill try this approach to get it back on the stack! Thanks! > > > > >> > >> Althogh to be honest, it's not super clear to me what the benefit of t= he bitmap > >> is vs just iterating through the PTEs like Dev does; is there a signif= icant cost > >> saving in practice? On the face of it, it seems like it might be uneed= ed complexity. > > The bitmap was to encode the state of PMD without needing rescanning > > (or refactor a lot of code). We keep the scan runtime constant at 512 > > (for x86). Dev did some good analysis for this here > > https://lore.kernel.org/lkml/23023f48-95c6-4a24-ac8b-aba4b1a441b4@arm.c= om/ > > This prevents needing to hold the read lock for longer, and prevents > > needing to reacquire it too. > >>>>> - The recursion is masked through a stack structure. > >>> - A MTHP_MIN_ORDER was added to compress the bitmap, and ensure it w= as > >>> 64bit on x86. This provides some optimization on the bitmap opera= tions. > >>> if other arches/configs that have larger than 512 PTEs per PMD wa= nt to > >>> compress their bitmap further we can change this value per arch. > >> > >> So 1 bit in the bitmap represents 8 pages? And it will only be set if = all 8 > >> pages are !pte_none()? I'm wondering what will happen if you have a pa= ttern of 4 > >> set PTEs followed by 4 none PTEs, followed by 4 set PTEs... If 16K mTH= P is > >> enabled, you would want to collapse every other 16K block in this case= , but I'm > >> guessing with your scheme, all the bits will be clear and no collapse = will > >> occur? But for arm64 at least, collapsing to order-2 (16K) may be desi= red for HPA. > > > > Yeah on my V2 ive incorporated a threshold (like max_ptes_none) for > > setting the bit. This will covert this case better (given a better > > default max_ptes_none). > > The way i see it 511 max_ptes_none is just wrong... > > You mean it's a bad default? Yeah that's the better phrasing. > > > we should flip it > > towards the lower end of the scale (ie 64), and the "always" THP > > setting should ignore it (like madvise does). > > But user space can already get that behaviour by modifying the tunable, r= ight? > Isn't that just a user space policy choice? technically yes, but shouldn't defaults reflect sane behavior? ofc this is my opinion, some might think 511 is not a bad default at all. My original perspective comes from the memory waste issue, 511 could be really good for performance if you benefit from PMDs; hence why I was also suggesting "always" ignores the max_ptes_none. > > One other thing that occurs to me regarding the bitmap; In the context of= Dev's > series, we have discussed policy for what to do when the source PTEs are = backed > by a large folio already. I'm guessing if you are making your > smaller-than-PMD-size collapse decisions based solely on the bitmap, you = won't > be able to see when the PTEs are already collpsed for the target order? i= .e. > let's say you already have a 64K folio fully mapped in an aligned way. Yo= u > wouldn't want to "re-collapse" it to 64K. Are you robust to this? Yes, I am also skipping the order <=3D folio_order case. > > > > >> > >>> > >>> Patch 1-2: Some refactoring to combine madvise_collapse and khugepag= ed > >>> Patch 3: A minor "fix"/optimization > >>> Patch 4: Refactor/rename hpage_collapse > >>> Patch 5-7: Generalize khugepaged functions for arbitrary orders > >>> Patch 8-11: The mTHP patches > >>> > >>> This series acts as an alternative to Dev Jain's approach [1]. The tw= o > >>> series differ in a few ways: > >>> - My approach uses a bitmap to store the state of the linear scan_p= md to > >>> then determine potential mTHP batches. Devs incorporates his dire= ctly > >>> into the scan, and will try each available order. > >> > >> So if I'm understanding, the benefit of the bitmap is to remove the ne= ed to > >> re-scan the "low" PTEs when moving to a lower order, which is what Dev= 's > >> approach does? Are there not some locking/consistency issues to manage= if not > >> re-scanning? > > Correct, so far i haven't found any issues (other than the bugs Dev > > reported in his review)-- my fixed version of this RFC has been > > running fine with no notable locking issues. > >> > >>> - Dev is attempting to optimize the locking, while my approach keep= s the > >>> locking changes to a minimum. I believe his changes are not safe = for > >>> uffd. > >> > >> I agree; let's keep the locking simple for the initial effort. > >> > >>> - Dev's changes only work for khugepaged not madvise_collapse (alth= ough > >>> i think that was by choice and it could easily support madvise) > >> > >> I agree supporting MADV_COLLAPSE is good; what exactly are the semanti= cs for it > >> though? I think it ignores the sysfs settings (max_ptes_none and frien= ds) so > >> presumably it will continue to be much more greedy about collapsing to= the > >> highest possible order and only fall back to lower orders if the VMA b= oundaries > >> force it to or if the higher order allocation fails? > > Kind of, because I removed the max_ptes_none check during the scan, > > and reintroduced it in the bitmap scan (without a madvise > > restriction), MADV_COLLAPSE and khugepaged will work more similarly. > >> > >>> - Dev scales all khugepaged sysfs tunables by order, while im remov= ing > >>> the restriction of max_ptes_none and converting it to a scale to > >>> determine a (m)THP threshold. > >> > >> I don't really understand this statement. You say you are removing the > >> restriction of max_ptes_none. But then you say you scale it to determi= ne a > >> threshold. So are you honoring it or not? And if you're honouring it, = how is > >> your scaling method different to Dev's? What about the other tunables = (shared > >> and swap)? > > I removed the max_ptes_none restriction during the initial scan, so we > > can account for the full PMD (which is what happens with > > max_ptes_none=3D511 anyways). Then max_ptes_none can be used with the > > bitmap to calculate a threshold (max_ptes_none=3D64 =3D=3D ~90% full) f= or > > finding the optimal mTHP size. > > > > This RFC scales max_ptes_none to 0-100, but it has some really bad > > rounding issues, so instead ive incorporated scaling (via bitshifting) > > like Dev did in his series. Ive tested this and it's more accurate > > now. > >> > >>> - Dev turns on khugepaged if any order is available while mine stil= l > >>> only runs if PMDs are enabled. I like Dev's approach and will mos= t > >>> likely do the same in my PATCH posting. > >> > >> Agreed. Also, we will want khugepaged to be able to scan VMAs (or part= s of VMAs) > >> that cover only a partial PMD entry. I think neither of your implement= ations > >> currently do that. As I understand it, Dev's v2 will add that support.= Is your > >> approach ammeanable to this? > > > > Yes, I believe so. I'm working on adding this too. > > > >> > >>> - mTHPs need their ref count updated to 1< >>> > >>> Patch 11 was inspired by one of Dev's changes. > >> > >> I think the 1 problem that emerged during review of Dev's series, whic= h we don't > >> have a proper solution to yet, is the issue of "creep", where regions = can be > >> collapsed to progressively higher orders through iterative scans. At e= ach > >> collapse, the required thresholds (e.g. max_ptes_none) are met, and th= e collapse > >> effectively adds more non-none ptes so the next scan will then collaps= e to even > >> higher order. Does your solution suffer from this (theoretical/edge ca= se) issue? > >> If not, how did you solve? > > > > Yes sadly it suffers from the same issue. bringing max_ptes_none much > > lower as a default would "help". > > I liked Zi Yan's solution of a per-VMA bit that gets set when > > khugepaged collapses, and unset when the VMA changes (pf, realloc, > > etc). > > Then khugepaged can only operate on VMAs that dont have the bit set. > > This way we only collapse once, unless the mapping was changed. > > Dev raised the issue in discussion against his series, that currently khu= gepaged > doesn't scan the entire VMA, it scans to the first PMD that it collapses = then > moves to another VMA. I guess that's a fairness thing. So a VMA flag won'= t quite > do the trick assuming we want to continue with that behavior. Perhaps we = could > keep a "cursor" in the VMA though, which describes the starting address o= f the > next scan. We can move it forwards as we scan. And move it backwards when= taking > a fault. Still not perfect, but perhaps good enough? I started playing around with some of these changes, it seems to work, but David raised the issue that we can't expand vm_struct, so I need to find a different solution. > > > > > Could we map the new "non-none" pages to the zero page (rather than > > actually zeroing the page), so they dont actually act as new "utilized > > pages" and are still counted as none pages during the scan (until they > > are written to)? > > I think you are propsing to use the zero page as a PTE marker to say "thi= s > region is scheduled for collapse"? In which case, why not just use a PTE > marker... But you still have to do the collapse at some point (which I gu= ess you > are now deferring to the next page fault that hits one of those markers)?= Once > you have collapsed, you're still back to the original issue. So I don't t= hink > it's bought you anything except complexity and more latency :) Ah ok i see! Thanks for clarifying > > Thanks, > Ryan > > > > >> > >> Thanks, > >> Ryan > > > > Cheers! > > -- Nico > > > >> > >> > >>> > >>> [1] https://lore.kernel.org/lkml/20241216165105.56185-1-dev.jain@arm.= com/ > >>> > >>> Nico Pache (11): > >>> introduce khugepaged_collapse_single_pmd to collapse a single pmd > >>> khugepaged: refactor madvise_collapse and khugepaged_scan_mm_slot > >>> khugepaged: Don't allocate khugepaged mm_slot early > >>> khugepaged: rename hpage_collapse_* to khugepaged_* > >>> khugepaged: generalize hugepage_vma_revalidate for mTHP support > >>> khugepaged: generalize alloc_charge_folio for mTHP support > >>> khugepaged: generalize __collapse_huge_page_* for mTHP support > >>> khugepaged: introduce khugepaged_scan_bitmap for mTHP support > >>> khugepaged: add mTHP support > >>> khugepaged: remove max_ptes_none restriction on the pmd scan > >>> khugepaged: skip collapsing mTHP to smaller orders > >>> > >>> include/linux/khugepaged.h | 4 +- > >>> mm/huge_memory.c | 3 +- > >>> mm/khugepaged.c | 436 +++++++++++++++++++++++++----------= -- > >>> 3 files changed, 306 insertions(+), 137 deletions(-) > >>> > >> > > >