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 F0389C433EF for ; Sat, 5 Mar 2022 00:18:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C59B8D0002; Fri, 4 Mar 2022 19:18:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 24B428D0001; Fri, 4 Mar 2022 19:18:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0EC8E8D0002; Fri, 4 Mar 2022 19:18:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 0035F8D0001 for ; Fri, 4 Mar 2022 19:18:30 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id CAB1F61B2C for ; Sat, 5 Mar 2022 00:18:30 +0000 (UTC) X-FDA: 79208421180.14.71B1D5A Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by imf05.hostedemail.com (Postfix) with ESMTP id 54C76100008 for ; Sat, 5 Mar 2022 00:18:30 +0000 (UTC) Received: by mail-pg1-f172.google.com with SMTP id o26so8772769pgb.8 for ; Fri, 04 Mar 2022 16:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=saZ72BekMK8qsFjf6iFKP3QgKwC49DlwyTRsuhEWNlU=; b=gwam8yL2b++JszTOUvQ0ZXj+nmxn/AeosTKqj5LA+ZurbbaluVNjYpt7294X4BayxN fhIu4Q6MVn9byBvLRMHn1RIACp028V8aYo/yJLOt18QDujL5aTCc//jGMpZrHImdAZuo AYSRaWYQEYtw8WRXSVcZAr9gXGbw4qZ+BnkfHI3QvfzMVzYbb1uY64tsIxe0idkL8U6/ IRIn9/mY/fL+fDvJACGZ3r879hn5ZNmsMiUhriRE0yJ0yZp+ytAZrEYH80MmKBtP55kD PetQ7yC5W7lc5P/VnrAZCAJ2dfpxg++d/Vj4hupboS65MQ0Kq+F04aSbwM0vvilleeQx XS/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=saZ72BekMK8qsFjf6iFKP3QgKwC49DlwyTRsuhEWNlU=; b=y9WRFRgeDxZn1eoyo6dYm/dNJf/vvx8NvCd7ycMSNOz2qdPXfhcgkWkzQsqXz7kHGq k1s+A7bNrrKGC76tJNgRYMcCoElSIsTKRRnVfupdUxHNB6O7meXhA+TtxyUj8yKVQ/hR YylAClLRMY6WNCRd0M66OTbAbnO4ahF15sEWh9j4AODeiNjqaJ9kZAHNJvqsIitZvzPK tLySnPes+2gp27q3apKr/kJrpKcg4EqiNQwj4e2UFbW0zFLjUYspJrhvd1pn0kH7NhsH HilYayghjCkz7QUaA37T1tzeNB7peBf9n7ANSl+ya6Uzo1ig5LH7coeMjyRrB1OXfRII jPbA== X-Gm-Message-State: AOAM531xeWFSrylZ4DexAZTXncAPZ9O4xKCVaaZ6gK5rp6uDTnMSI9IJ K0wSU74Y/onpM/USXMSGyMY= X-Google-Smtp-Source: ABdhPJwZvhbbHcXl8W9nWnyHp4jwWRWthrOgPp66Ud7SEJtRpKdsfE59ysfxLrdisS3itYKLLWgulQ== X-Received: by 2002:a65:6901:0:b0:378:8154:e2bf with SMTP id s1-20020a656901000000b003788154e2bfmr725432pgq.401.1646439509059; Fri, 04 Mar 2022 16:18:29 -0800 (PST) Received: from google.com ([2620:15c:211:201:b771:f8fb:2968:865c]) by smtp.gmail.com with ESMTPSA id n22-20020a056a0007d600b004f11e614565sm7021714pfu.189.2022.03.04.16.18.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Mar 2022 16:18:28 -0800 (PST) Date: Fri, 4 Mar 2022 16:18:26 -0800 From: Minchan Kim To: Ivan Teterevkov Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, mhocko@suse.com, hannes@cmpxchg.org, timmurray@google.com, joel@joelfernandes.org, surenb@google.com, dancol@google.com, shakeelb@google.com, sonnyrao@google.com, oleksandr@redhat.com, hdanton@sina.com, lizeb@google.com, dave.hansen@intel.com, kirill.shutemov@linux.intel.com Subject: Re: Regression of madvise(MADV_COLD) on shmem? Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 54C76100008 X-Stat-Signature: 3w7fc61r6zhdc3ehxh77ekr5sopdt9xe Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=gwam8yL2; spf=pass (imf05.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-Rspam-User: X-HE-Tag: 1646439510-183678 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: On Fri, Mar 04, 2022 at 05:55:58PM +0000, Ivan Teterevkov wrote: > Hi folks, > > I want to check if there's a regression in the madvise(MADV_COLD) behaviour > with shared memory or my understanding of how it works is inaccurate. > > The MADV_COLD advice was introduced in Linux 5.4 and allowed the users to > mark selected memory ranges as more "inactive" than others, overruling the > default LRU accounting. It helped to preserve the working set of an > application. With more recent kernels, e.g. at least 5.17.0-rc6 and 5.10.42, > MADV_COLD has stopped working as expected. Please take a look at a short > program that demonstrates it: > > /* > * madvise(MADV_COLD) demo. > */ > #include > #include > #include > #include > #include > > /* Requires the kernel 5.4 or newer. */ > #ifndef MADV_COLD > #define MADV_COLD 20 > #endif > > #define GIB(x) ((size_t)(x) << 30) > > int main(void) > { > char *shmem, *zeroes; > int page_size = getpagesize(); > size_t i; > > /* Allocate 8 GiB of shared memory. */ > shmem = mmap(/* addr */ NULL, > /* length */ GIB(8), > /* prot */ PROT_READ | PROT_WRITE, > /* flags */ MAP_SHARED | MAP_ANONYMOUS, > /* fd */ -1, > /* offset */ 0); > assert(shmem != MAP_FAILED); > > /* Allocate a zero page for future use. */ > zeroes = calloc(1, page_size); > assert(zeroes != NULL); > > /* Put 1 GiB blob at the beginning of the shared memory range. */ > memset(shmem, 0xaa, GIB(1)); > > /* Read memory adjacent to the blob. */ > for (i = GIB(1); i < GIB(8); i = i + page_size) { > int res = memcmp(shmem + i, zeroes, page_size); > assert(res == 0); > > /* Cooldown a zero page and make it "less active" than the blob. > * Under memory pressure, it'll likely become a reclaim target > * and thus will help to preserve the blob in memory. > */ > res = madvise(shmem + i, page_size, MADV_COLD); > assert(res == 0); > } > > /* Let the user check smaps. */ > printf("done\n"); > pause(); > > free(zeroes); > munmap(shmem, GIB(8)); > > return 0; > } > > How to run this program: > > 1. Create a "test" cgroup with a memory limit of 3 GiB. > > 1.1. cgroup v1: > > # mkdir /sys/fs/cgroup/memory/test > # echo 3G > /sys/fs/cgroup/memory/test/memory.limit_in_bytes > > 1.2. cgroup v2: > > # mkdir /sys/fs/cgroup/test > # echo 3G > /sys/fs/cgroup/test/memory.max > > 2. Enable at least a 1 GiB swap device. > > 3. Run the program in the "test" cgroup: > > # cgexec -g memory:test ./a.out > > 4. Wait until it has finished, i.e. has printed "done". > > 5. Check the shared memory VMA stats. > > 5.1. In 5.17.0-rc6 and 5.10.42: > > # cat /proc/$(pidof a.out)/smaps | grep -A 21 -B 1 8388608 > 7f8ed4648000-7f90d4648000 rw-s 00000000 00:01 2055 /dev/zero > (deleted) > Size: 8388608 kB > KernelPageSize: 4 kB > MMUPageSize: 4 kB > Rss: 3119556 kB > Pss: 3119556 kB > Shared_Clean: 0 kB > Shared_Dirty: 0 kB > Private_Clean: 3119556 kB > Private_Dirty: 0 kB > Referenced: 0 kB > Anonymous: 0 kB > LazyFree: 0 kB > AnonHugePages: 0 kB > ShmemPmdMapped: 0 kB > FilePmdMapped: 0 kB > Shared_Hugetlb: 0 kB > Private_Hugetlb: 0 kB > Swap: 1048576 kB > SwapPss: 0 kB > Locked: 0 kB > THPeligible: 0 > VmFlags: rd wr sh mr mw me ms sd > > 5.2. In 5.4.109: > > # cat /proc/$(pidof a.out)/smaps | grep -A 21 -B 1 8388608 > 7fca5f78b000-7fcc5f78b000 rw-s 00000000 00:01 173051 /dev/zero > (deleted) > Size: 8388608 kB > KernelPageSize: 4 kB > MMUPageSize: 4 kB > Rss: 3121504 kB > Pss: 3121504 kB > Shared_Clean: 0 kB > Shared_Dirty: 0 kB > Private_Clean: 2072928 kB > Private_Dirty: 1048576 kB > Referenced: 0 kB > Anonymous: 0 kB > LazyFree: 0 kB > AnonHugePages: 0 kB > ShmemPmdMapped: 0 kB > FilePmdMapped: 0 kB > Shared_Hugetlb: 0 kB > Private_Hugetlb: 0 kB > Swap: 0 kB > SwapPss: 0 kB > Locked: 0 kB > THPeligible: 0 > VmFlags: rd wr sh mr mw me ms > > There's a noticeable difference in the "Swap" reports so that the older > kernel doesn't swap the blob, but the newer ones do. > > According to ftrace, the newer kernels still call deactivate_page() in > madvise_cold(): > > # trace-cmd record -p function_graph -g madvise_cold > # trace-cmd report | less > a.out-4877 [000] 1485.266106: funcgraph_entry: | madvise_cold() { > a.out-4877 [000] 1485.266115: funcgraph_entry: | walk_page_range() > { > a.out-4877 [000] 1485.266116: funcgraph_entry: | > __walk_page_range() { > a.out-4877 [000] 1485.266117: funcgraph_entry: | > madvise_cold_or_pageout_pte_range() { > a.out-4877 [000] 1485.266118: funcgraph_entry: 0.179 us | > deactivate_page(); > > (The irrelevant bits are removed for brevity.) > > It makes me think there may be a regression in MADV_COLD. Please let me know > what do you reckon? Since deactive_page is called, I guess that's not a regression(?) from [1] Then, my random guess that you mentioned "Swap" as regression might be related to "workingset detection for anon page" since kernel changes balancing policy between file and anonymous LRU, which was merged into v5.8. It would be helpful to see if you try it on v5.7 and v5.8. [1] 12e967fd8e4e6, mm: do not allow MADV_PAGEOUT for CoW page