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 50843C433F5 for ; Thu, 24 Feb 2022 20:38:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81EA38D0001; Thu, 24 Feb 2022 15:38:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A6B48D0002; Thu, 24 Feb 2022 15:38:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A0318D0001; Thu, 24 Feb 2022 15:38:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0039.hostedemail.com [216.40.44.39]) by kanga.kvack.org (Postfix) with ESMTP id 5711A8D0001 for ; Thu, 24 Feb 2022 15:38:22 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id EC8CF181CC433 for ; Thu, 24 Feb 2022 20:38:21 +0000 (UTC) X-FDA: 79178836002.21.577B0CD Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf08.hostedemail.com (Postfix) with ESMTP id 2AA5916000A for ; Thu, 24 Feb 2022 20:38:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=sKjrF+K3GoAKCM7yt6kgQokeyvGFBlwxCvFD5Flde2w=; b=ci4OpPI0VQ4INnhFq3PDcPJCM7 Knf7etQ0ywlHaMgW35DeOB6Ynvd/7IvdeWD7SBe36RkLCNzlARw9Bn+gWMEq2K0YQAYRVLO7+bKZy CP+mRaqsaSbJwhQYbDLAk3R2B1NdVdkG54g4G6j1dPQCZdBI4OFei71qqQAA/myNJhms0GC/xp7i5 jOwBA2wQDFIHwZnLNCJc5gGC2qC05pRE6bsENhq/Dk4vj/8Lg5DCZohTKb0eqIUHlHkmrLX7raAjM uh5mCXTps49/QOY0zkMPdBwGWF5gMTlEs66kNmSLwh3mhIAjuoef6HkIq4FUV0I1NbEs82WrLQW3Q FxRHqKhw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nNKQR-0056LI-5I; Thu, 24 Feb 2022 20:09:19 +0000 Date: Thu, 24 Feb 2022 20:09:19 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: lsf-pc@lists.linux-foundation.org, "linux-mm@kvack.org" Subject: Re: [LSF/MM/BPF TOPIC] page table reclaim Message-ID: References: <7b908208-02f8-6fde-4dfc-13d5e00310a6@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7b908208-02f8-6fde-4dfc-13d5e00310a6@redhat.com> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 2AA5916000A X-Stat-Signature: t67xtatxkxjw45qqjqwckngazd7ipf5e Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ci4OpPI0; spf=none (imf08.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-HE-Tag: 1645735101-961567 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 Tue, Feb 22, 2022 at 09:56:20AM +0100, David Hildenbrand wrote: > 2. Who triggers reclaim and when? > > Letting an application trigger reclaim of page tables is the "easiest > solution": let's imagine madvise(MADV_RECLAIM_PGTABLES). However, this > doesn't take care of malicious workloads and is more problematic when > having sparse files mapped into multiple processes. Further, there is no > need to reclaim if we're not under memory pressure. > > Letting the system do this automatically looks "cleaner". But, when to > start reclaiming? How to detect and handle malicious processes (do we > care?)? How to set an adequate soft/hard limit? I don't think we care about the difference between users that are performing useful work with an inefficient page table strategy and users that are trying to break the page table usage scheme. We have to account the page tables to each process (which we already do), and a process which is, say, trying to allocate memory might be shunted off to a path where it tries to reclaim its own page tables if it has a lot on the books. Particularly if it's trying to allocate memory for more page tables ;-) > While I do have answers to some of the questions and various ideas, it's > certainly an interesting topic to discuss and brainstorm. Indeed; it interests me too.