From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5D67D10F2 for ; Sun, 21 Dec 2025 02:10:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766283049; cv=none; b=RGYCyyaVDFeaZwZA14a6fHs2XjdKYc+qxUNBfUec0SrfMUiEga5WSEUF4+0oL0vt3Jfopx3GQ15YU9c6PC8dUa2ZzH7sVq6sPbzyCECNW1G6oUkg9kmZP5qXdZyEqhDXYjOVkxNCSwFfPXRKJU5xCJ/vkB3s6DYd6mSvDsPfACY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766283049; c=relaxed/simple; bh=fyHuijB2cUOMtrcOc6pEg+JcOxAQM8CSr48pPNhK7fA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=t1Ah68hh2/csxCq6u18eLln02plUHq8oYNC8cjEXauMhkL0XCzRWQrOjDhv7XYf0NLgM2EFr1/zcCQv7eTqx6WpLn1HtmbiqyhjtJayjggqkosTDFZz1DRQxXN4P+WN1QgI49VX5bHWBQAJHpSGSwy8q6SKmx49xRx8/mWJg5D8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=l3x/O6xf; arc=none smtp.client-ip=209.85.218.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="l3x/O6xf" Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-b7697e8b01aso551533166b.2 for ; Sat, 20 Dec 2025 18:10:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766283046; x=1766887846; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=D1IALJoem7ouE554nQQ0FVgOHYidFgLlzbJ1kR8CnYw=; b=l3x/O6xf3Wb+UfWEc9gKpQZ5tWRzrwf7ohGFdxxdqVu+gAjiz3pLwh7wofLvJ7fh2M PvumyROgg8wG0Z1VqnhmlWVw0gcnWdaTOcJ8CLmdcYs7H5MoUGQUNlQlQ7m9YkHOA62n NdnQbLiCrqGRnPv7ufeIeQu9bMtji9Be87w+NuAXnaP5l+4zkA/zvqseD40m56Nvb0Re OyD+YfchuJRge0fqF0rMFjYJcJiAcOEnPLA1HXtSVjTnNlAYz9kSwWXELYV2nAyCEWK9 4/eQufx7fV40BRVKZuKj9bnPq6EzR1wdhnOStyAAeOhp5+eyClJ2nbr5dJckDBRx2FST ejfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766283046; x=1766887846; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=D1IALJoem7ouE554nQQ0FVgOHYidFgLlzbJ1kR8CnYw=; b=imkuqs7FX4kfNngvXsp7dl3uZEknrFR4gvR4tqfa5+LqSVa5VMa1L8yGeENbwxR6zp uYBl9YKykPJWbBSlYouz5zITJWLbWknjEokwlCPVDQiIpdEIUBHBWxPcRBn2Kk61gkUT zFClXw5jto8EPcFOoelH5M4hiLYI0W1it5Y9zehg4ZjGwZnP8tpKGeCUV1P6QoJ22/yp gZpSWimutbo3MRQAIUpLpczq6Yok5W+x5bLNZW1ntEkfXLE1LXHfWpV7LQz0GXzTtg8E 3/5TlKPDbU4jxGHsit2EwK4aW3GtBcsX1ByS9p19LhZz6Se7RWvcKfBJgM019SjbDSA4 FOLg== X-Forwarded-Encrypted: i=1; AJvYcCXTGT4/snCmP2mBVjfkVjIEeEgtCdleNb6LU5CVF+c7egaTxpozgieE3QXMjS8WRRLZIXHmpFTbDLoLjEs=@vger.kernel.org X-Gm-Message-State: AOJu0YxXUbyfUUyeAwwi92TdHE3dulSmvmYSutNfeXl0dyJWSSI6cvBl cZTtQGNJyVYOGSpe7W+AarzuS9gVAic+GlGAgBKHAd7xhOmpQRXWdVm2 X-Gm-Gg: AY/fxX6C3LcEmuuoq5VWbj9y4dIn3r+aXKmAMVUbW/2uzyE251GnH+5mEW+XeWz6up8 G4xWlKWaNUbz5lQzdksyB2x1P7HZ0yWbXT5mdylBStjxPRxDa4R9b/BTKdlh9ugVn1YgqIpsIlw WUs2epjv0MJ8ffWuoJwuGb6mTZIQI3ECaFv7CNjdBcux5GxSjI5ON5J+3heMxm9phkAPgOs1x5Z eftNN6iOEAmPDLXcTKwMMH4PiAw/juusRktGaNKyQrVZpDjiTY4fW7VCncPN/5/6mBejAwUZlQb DcDUmSn6Of0vzichOdT1LaMQv0YmemnggVRVEgkzrureLQgCMoU2uzG9JrdbmFNUAVESaKvz2Hr WOTgfVh+tD/1Nwy2+PWKaLoIRRVuZKVW705X+hu1bX805HdDMdEK5ST9QVB/VPyvfjUx/2ZX6Nm 684fn8D40bkQZQ6NGrWMSB X-Google-Smtp-Source: AGHT+IF4/pDPAGPL8ps7I03GKKyl4mXVQ7FCC68KL0NGqUkYi3qeo9Ix8Rj3iK3veky8o7Cb9LbRFQ== X-Received: by 2002:a17:907:6e91:b0:b73:8639:334a with SMTP id a640c23a62f3a-b8036ebd999mr686070466b.13.1766283045562; Sat, 20 Dec 2025 18:10:45 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8037a604f5sm653526466b.11.2025.12.20.18.10.44 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sat, 20 Dec 2025 18:10:45 -0800 (PST) Date: Sun, 21 Dec 2025 02:10:44 +0000 From: Wei Yang To: "David Hildenbrand (Red Hat)" Cc: Vernon Yang , akpm@linux-foundation.org, lorenzo.stoakes@oracle.com, ziy@nvidia.com, baohua@kernel.org, lance.yang@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vernon Yang Subject: Re: [PATCH 3/4] mm: khugepaged: move mm to list tail when MADV_COLD/MADV_FREE Message-ID: <20251221021044.2r5fhepiyyhvuo7h@master> Reply-To: Wei Yang References: <20251215090419.174418-1-yanglincheng@kylinos.cn> <20251215090419.174418-4-yanglincheng@kylinos.cn> <3c75d915-5d7f-4e80-975f-4479393e7139@kernel.org> <6e8684a5-1f71-4be6-8805-9b047a2bcb78@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6e8684a5-1f71-4be6-8805-9b047a2bcb78@kernel.org> User-Agent: NeoMutt/20170113 (1.7.2) On Fri, Dec 19, 2025 at 09:58:17AM +0100, David Hildenbrand (Red Hat) wrote: >On 12/19/25 06:29, Vernon Yang wrote: >> On Thu, Dec 18, 2025 at 10:31:58AM +0100, David Hildenbrand (Red Hat) wrote: >> > On 12/15/25 10:04, Vernon Yang wrote: >> > > For example, create three task: hot1 -> cold -> hot2. After all three >> > > task are created, each allocate memory 128MB. the hot1/hot2 task >> > > continuously access 128 MB memory, while the cold task only accesses >> > > its memory briefly andthen call madvise(MADV_COLD). However, khugepaged >> > > still prioritizes scanning the cold task and only scans the hot2 task >> > > after completing the scan of the cold task. >> > > >> > > So if the user has explicitly informed us via MADV_COLD/FREE that this >> > > memory is cold or will be freed, it is appropriate for khugepaged to >> > > scan it only at the latest possible moment, thereby avoiding unnecessary >> > > scan and collapse operations to reducing CPU wastage. >> > > >> > > Here are the performance test results: >> > > (Throughput bigger is better, other smaller is better) >> > > >> > > Testing on x86_64 machine: >> > > >> > > | task hot2 | without patch | with patch | delta | >> > > |---------------------|---------------|---------------|---------| >> > > | total accesses time | 3.14 sec | 2.92 sec | -7.01% | >> > > | cycles per access | 4.91 | 2.07 | -57.84% | >> > > | Throughput | 104.38 M/sec | 112.12 M/sec | +7.42% | >> > > | dTLB-load-misses | 288966432 | 1292908 | -99.55% | >> > > >> > > Testing on qemu-system-x86_64 -enable-kvm: >> > > >> > > | task hot2 | without patch | with patch | delta | >> > > |---------------------|---------------|---------------|---------| >> > > | total accesses time | 3.35 sec | 2.96 sec | -11.64% | >> > > | cycles per access | 7.23 | 2.12 | -70.68% | >> > > | Throughput | 97.88 M/sec | 110.76 M/sec | +13.16% | >> > > | dTLB-load-misses | 237406497 | 3189194 | -98.66% | >> > >> > Again, I also don't like that because you make assumptions on a full process >> > based on some part of it's address space. >> > >> > E.g., if a library issues a MADV_COLD on some part of the memory the library >> > manages, why should the remaining part of the process suffer as well? >> >> Yes, you make a good point, thanks! >> >> > This seems to be an heuristic focused on some specific workloads, no? >> >> Right. >> >> Could we use the VM_NOHUGEPAGE flag to indicate that this region should >> not be collapsed, so that khugepaged can simply skip this VMA during >> scanning? This way, it won't affect the remaining part of the task's >> memory regions. > >I thought we would skip these regions already properly in khugeapged, or >maybe I misunderstood your question. > I think we should, but seems we didn't do this for anonymous memory during khugepaged. We check the vma with thp_vma_allowable_order() during scan. * For anonymous memory during khugepaged, if we always enable 2M collapse, we will scan this vma. Even VM_NOHUGEPAGE is set. * For other cases, it looks good since __thp_vma_allowable_order() will skip this vma with vma_thp_disabled(). >-- >Cheers > >David -- Wei Yang Help you, Help me