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 763B6C41535 for ; Fri, 22 Dec 2023 15:40:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED4DA6B0078; Fri, 22 Dec 2023 10:40:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E86266B007B; Fri, 22 Dec 2023 10:40:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D737B6B007D; Fri, 22 Dec 2023 10:40:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id C7B826B0078 for ; Fri, 22 Dec 2023 10:40:47 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8AC86409B6 for ; Fri, 22 Dec 2023 15:40:47 +0000 (UTC) X-FDA: 81594866934.25.1D93102 Received: from out0-202.mail.aliyun.com (out0-202.mail.aliyun.com [140.205.0.202]) by imf11.hostedemail.com (Postfix) with ESMTP id B2E264000A for ; Fri, 22 Dec 2023 15:40:42 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=antgroup.com; spf=pass (imf11.hostedemail.com: domain of henry.hj@antgroup.com designates 140.205.0.202 as permitted sender) smtp.mailfrom=henry.hj@antgroup.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703259645; 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; bh=umQ1Kf4ezSraBidPnhVIzeWunCloE/CW0wcXFbztK+A=; b=Sf7Q2gKvD4GWEJcdeNRI7186q9SkhoAry3+PyE+vKG6NE5qQ3b7HIvYQygH73/1kA5tS2G IRUCNWzw2J2sTgM8tlmeWDy77be1h2n1FTzAxZz88RKDv2oGyBCryYRW3H8b8qodqKqGu/ dL3YmrCAwfn8TQUDnGD5E9YRwqlQXdU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=antgroup.com; spf=pass (imf11.hostedemail.com: domain of henry.hj@antgroup.com designates 140.205.0.202 as permitted sender) smtp.mailfrom=henry.hj@antgroup.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703259645; a=rsa-sha256; cv=none; b=HN9iRRGT8fsGzU8mEGjoGIpNYHBBhvW8KB+p2amQmDwRkPoEkAcW6uR0BiZycqG3r0lwbf s0nx/m39kd4Ys36j83CqoGM+RHlF0VNMIXneVvNmlmVmsyWs02wazAdKwHceIntBySL0WR CN4Wurt8In47wE3XQeP7LKx2fRTVxsE= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018047198;MF=henry.hj@antgroup.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---.Vqjmyjt_1703259637; Received: from localhost(mailfrom:henry.hj@antgroup.com fp:SMTPD_---.Vqjmyjt_1703259637) by smtp.aliyun-inc.com; Fri, 22 Dec 2023 23:40:38 +0800 From: "Henry Huang" To: rientjes@google.com Cc: , "Henry Huang" , "=?UTF-8?B?6LCI6Ym06ZSL?=" , , , "=?UTF-8?B?5pyx6L6JKOiMtuawtCk=?=" , , Subject: Re: [RFC v2] mm: Multi-Gen LRU: fix use mm/page_idle/bitmap Date: Fri, 22 Dec 2023 23:40:33 +0800 Message-ID: <20231222154037.62823-1-henry.hj@antgroup.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <931f2e6d-30a1-5f10-e879-65cb11c89b85@google.com> References: <931f2e6d-30a1-5f10-e879-65cb11c89b85@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: B2E264000A X-Stat-Signature: jw3fbuti8tqwmgmgzy6kh6ec3uada59h X-HE-Tag: 1703259642-891153 X-HE-Meta: U2FsdGVkX19YpjHD/ezSWs+agNdBdimiLCzdGimbE3GRkV1g+4Rgy1QMZr4Rhe0pbSZi1UNCYEQOdDT6lW7g1mzQrzSWjLZ2LDI344k0nCxbs1ye82uEDsb829montI5EipzUnvlyr60yzI6gEjabNXjN/ygvBYoA1/1xAjYn0Xd6iK4xm913x6HArX2lKhrIKMnqLw4K5Ya+w13WnB6R1h15rHXQNxrObcFnW2k5BNXugq8M6A8oJl7fgBonEjTQQIXNTZHpSf1TjdvlPHTDVIPuY6YkzLF9D8vXDQVZYOqCNMp2U8s07oquuc0RMyVURg/j2hvVR+OHI0Qver6mGEV91as6bmIdoF+YhOnqax13VMFKv9Ah5sTBOy+SokOPMxlNE3QNgkvwY2iX7gumHTd4nDLbspJvuXLhBXfKlYA4e3P8HesvRqaArFlR1SzEg7CI/Ym3ne0yW0YWXVHvfQkiQmEqjFDtkXWhzVhGMvKqcm4MBDJoxeyAn4gAtxOkoHduJ1pgBlIyMxVEo4iD0HrfBT1Sf7IdN0FPvgllG2CTfYZP+mwFKy603o3KAAw5TUFt3zKyZNV6YJ5H5bqsfoZvQX4E1/duKLJpSdpL1h87Db24R6X3QSHbc19dZRoy5x5KPpIvKFLVO1jKGszjVrEjl+WtiDWd6GueeFSBLvxCXAoImqJ+xk6aU3NkbB3n0Io8fiZjshBKLQc0o+V1hSnGUpVN4lDGjjwtXIxYSA7Qs02oGuqTHhEfJlqO85ZGdIoM77kF5kYnRBOmEOaB8gxcW6AOI8aR60NxowipnNM/8qI3MVXqFQ/yPiOHwHrqFDCe/EVcVCVBbJ01tO1iFcjmXNJI0rRtcU9CysDDYTY4Y6VvsnOQEdZutEnGQyPjsdsaFID9hpCzhcjxWpy3PFjiwkKB0FZJ82fN6EtlK0ONyYV4dWH7sWlOfzPK6K4FEW7UnVXC75BNM9Nkdp 3WKECs+8 SZdsS6BLmbvLKoe/YBIOMBZ3LmClZj7ARElBRRx/aQa0u6vrjJtHBqDSQNApqp5BZcmFozsywvoyoYTErnS9/YRLFTXp9gyh6fBzqwcaBvc4GTsgKE0YUMApacFMuEUUjzX0qHpzL3a0zETTJ87P6MJTC5Obw4SY6lUB1hE5/MACVkFw30fE8fIqGFTsH0ljuwmbddO9v2+Zix2JeVTUCiln6IpignuYDzIiI6AK1fM8DHJhxk68BVsH4aw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000010, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Thanks for replying. On Fri, Dec 22, 2023 at 13:14 PM David Rientjes wrote: > - is the lack of predeterministic charging a problem for you? Are you > initially faulting it in a manner that charges it to the "right" memcg > and the refault of it after periodic reclaim can causing the charge to > appear "randomly," i.e. to whichever process happened to access it > next? Actually at begin, all pages got charged to cgroup A, but with memory pressure or after proactive reclaim. Some pages would be dropped or swapped. Task in cgroup B visit this shared memory before task in cgroup A, would make these pages charged to cgroup B. This is common in our enviorment. > - are pages ever shared between different memcg hierarchies? You > mentioned sharing between processes in A and A/B, but I'm wondering > if there is sharing between two different memcg hierarchies where root > is the only common ancestor? Yes, there is a another really common case: If docker graph driver is overlayfs, different docker containers use the same image, or share same low layers, would share file cache of public bin or lib(i.e libc.so). > - do you anticipate a shorter scan period at some point? Proactively > reclaiming all memory colder than one hour is a long time :) Are you > concerned at all about the cost of doing your current idle bit > harvesting approach becoming too expensive if you significantly reduce > the scan period? We don't want the owner of the application to feel a significant performance downgrade when using swap. There is a high risk to reclaim pages which idle age are less than 1 hour. We have internal test and data analysis to support it. We disabled global swappiness and memcg swapinness. Only proactive reclaim can swap anon pages. What's more, we see that mglru has a more efficient way to scan pte access bit. We perferred to use mglru scan help us scan and select idle pages. > - is proactive reclaim being driven by writing to memory.reclaim, by > enforcing a smaller memory.high, or something else? Because all pages info and idle age are stored in userspace, kernel can't get these information directly. We have a private patch include a new reclaim interface to support reclaim pages with specific pfns. -- 2.43.0