From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Weiner Subject: Re: [PATCH mm v6 4/4] mm: automatically penalize tasks with high swap use Date: Wed, 27 May 2020 16:05:30 -0400 Message-ID: <20200527200530.GA49331@cmpxchg.org> References: <20200527195846.102707-1-kuba@kernel.org> <20200527195846.102707-5-kuba@kernel.org> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=DWnL9S9WGTEGZuRBVdjP/jVDvy6htJ4NRm6fYZkzl3Y=; b=NTm+WSC85vpDh39BbXIYKURNZHjJKrwLhW+pSwDVbOMtLjTg+sROC2r1TgnVF1OQJT Z/+qWMAo9OaDwOtMZ35h9ZpEg8wgO3BAlWzDHpHSL5NVQUTCJ1bGJx6/6fy6SnXgg5Mm sRcUXPwwx6KDFyRWDqCOVko4xkFYLQeK0SUcGUMRAQwpQ8znovQguw8tU8jubSm8NX5k NN8fv1ZcfUBQ+ioRqagvGPVpPlH6peeyg50f2RCcHk36SNjEv1StDmpPr/igiJufMXgW r0OPMvAGHcAZuM+FcFT10yaa7c005AJgEA5QQNidQmLv5eEj1zntOfSGbVcYC3MSQDkq D0cQ== Content-Disposition: inline In-Reply-To: <20200527195846.102707-5-kuba-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Jakub Kicinski Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, kernel-team-b10kYP2dOMg@public.gmane.org, tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org On Wed, May 27, 2020 at 12:58:46PM -0700, Jakub Kicinski wrote: > Add a memory.swap.high knob, which can be used to protect the system > from SWAP exhaustion. The mechanism used for penalizing is similar > to memory.high penalty (sleep on return to user space). > > That is not to say that the knob itself is equivalent to memory.high. > The objective is more to protect the system from potentially buggy > tasks consuming a lot of swap and impacting other tasks, or even > bringing the whole system to stand still with complete SWAP > exhaustion. Hopefully without the need to find per-task hard > limits. > > Slowing misbehaving tasks down gradually allows user space oom > killers or other protection mechanisms to react. oomd and earlyoom > already do killing based on swap exhaustion, and memory.swap.high > protection will help implement such userspace oom policies more > reliably. > > We can use one counter for number of pages allocated under > pressure to save struct task space and avoid two separate > hierarchy walks on the hot path. The exact overage is > calculated on return to user space, anyway. > > Take the new high limit into account when determining if swap > is "full". Borrowing the explanation from Johannes: > > The idea behind "swap full" is that as long as the workload has plenty > of swap space available and it's not changing its memory contents, it > makes sense to generously hold on to copies of data in the swap > device, even after the swapin. A later reclaim cycle can drop the page > without any IO. Trading disk space for IO. > > But the only two ways to reclaim a swap slot is when they're faulted > in and the references go away, or by scanning the virtual address space > like swapoff does - which is very expensive (one could argue it's too > expensive even for swapoff, it's often more practical to just reboot). > > So at some point in the fill level, we have to start freeing up swap > slots on fault/swapin. Otherwise we could eventually run out of swap > slots while they're filled with copies of data that is also in RAM. > > We don't want to OOM a workload because its available swap space is > filled with redundant cache. > > Signed-off-by: Jakub Kicinski This looks great to me now, thanks Jakub! Acked-by: Johannes Weiner