Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1255708imu; Wed, 9 Jan 2019 14:39:43 -0800 (PST) X-Google-Smtp-Source: ALg8bN7c1N4Pl0IGVPvXXf33SDPZucyt6oZ4+lpMcHqMyU6J3TwQvVZ4zdj9pgcuHYJPavELJnzh X-Received: by 2002:a17:902:33c2:: with SMTP id b60mr7868386plc.211.1547073583331; Wed, 09 Jan 2019 14:39:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547073583; cv=none; d=google.com; s=arc-20160816; b=NARNtHa76oXI0He5NAwHa7a/DvWIHesO4GQBqqoUUsK+EdECx4PFyB0Ak/Pbkex2gx TGF0q0R3lnaqjDp4olOEXrCMDVcsApgBFaAuxO7cqBh6EsbvEvuDeLa5RJI3eZ5M9awT mfW036EzHjMFj2owM4kqPKXI4RSht6gkykHRIj5IhTiGqhR4Y/ZSo+GxOWdbFp/EU8PJ 8xyVuwcumI6HUuNvKOSAsC7sKPfQjfTD/yjEA43YkI0pJl5VNiIaGtP4ZD1ACjueC+QI Z23sIx9Tjqq6Sc4fJvGR08knhlsBV32DHMU7hNve+VumDrsLQBVObLFBWbpRvY3AYlD2 e8uw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=kfFoE86abS3p8Fs1VfcYmGgBPBRGbAxZVbI0XgjcWOE=; b=kI3+0pv65UT9IbL8ADHEvqtsJDvtdilhPJ6OEb1ml1PXCt0RH2LPLfrDgrXCX6CkEr gKu3ZnUgChCrsEAvpd8+dMmWPnv6doLrQwL+AGxNQk98K9UlRkpyawFzssr1hY6j6GTi 2SXHwwKPf0wLT2a19Obaup7pfD25Y2sQ4hWrV12Muyu9juXfEeEJnm5Ld0jhnAxuxUBR HiBP+iaDqoEChOxi8XlJ+Kv6S3obSd9DOWuHZ0/jI2AK5RzjhzLpiovlbR5ZmykRsG6Z tspUAXeYz+S/St6qXcP3J0ivux0hIFzXrMPzIpKdIaSR5FXDkGQAaMUBiexYqh7rvThY kc+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=gQCkCkBR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u24si13452841pgj.489.2019.01.09.14.39.28; Wed, 09 Jan 2019 14:39:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=gQCkCkBR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726946AbfAIVXi (ORCPT + 99 others); Wed, 9 Jan 2019 16:23:38 -0500 Received: from mail-yb1-f196.google.com ([209.85.219.196]:33150 "EHLO mail-yb1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725681AbfAIVXh (ORCPT ); Wed, 9 Jan 2019 16:23:37 -0500 Received: by mail-yb1-f196.google.com with SMTP id o73so3602474ybc.0 for ; Wed, 09 Jan 2019 13:23:36 -0800 (PST) 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:user-agent; bh=kfFoE86abS3p8Fs1VfcYmGgBPBRGbAxZVbI0XgjcWOE=; b=gQCkCkBRANwch9nBpN2mXOwU5nTY9Yi9e5cM+ZfzTUzr15AuQShCmzvmumgREGnX0a GNzAzRVC8wrd1gy1pYZlbBEHWestM29tSNpvivyYH2y7BmI5QiY+JH7CK6iYiIBb/FTh LjlipZf2PfnTq9fQ0yQiX1Je5l6oE6plLwXlrwyYLddPE/WGNX6CYNK3nwT1OP/QEcXn zIl3PDUlT0ksHLwqc7HEJYqeYfSbn+j1OGroY3omaplEMagiZRzf5ftf4HBMubUDOaqP QHw7osyPDV5QaAZpmO4t503bVrHOvHCyqf6dyZtOGZr8P3qQflUWyG05fXHYCstdbOfu eliA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=kfFoE86abS3p8Fs1VfcYmGgBPBRGbAxZVbI0XgjcWOE=; b=pf2BFV15q/FCCTPzxzlWKxZM4cHApW6ZegRdIWcZzlQ43qeM4f+KttMNtGtkpJiaW2 PE5F4uFMfKGXJwRDtDna4224W/rtf8LyH21icRl0m7Iq3dYs7O7jN377SgAp8MBzXVu5 QMxstouzqzKprPwUzHG6G4+UupSiDgH7mRjzRG4pAXvJYY7NqwPl0J8uJKEOJAR04qHo cCVuKJqRDndGMSnmAqyBlY1kQDVGiMIy3bQ0oIcM0j4ze40ONHnuLwUQA+WmESjgQbMI sFugFpFSwWAInqPp7ZB6zEBzZy8c6x09PcOx4k3UVYwdLwxHgV+kiMm+U07nZJZ78HRC sqmg== X-Gm-Message-State: AJcUukfahsoHWEonvqI21MPltLbXq9JRWEGtkpQgQvuy9Lze8BzaiMV6 /8t67syS83ufORXRUb3C2P6mdQ== X-Received: by 2002:a25:b321:: with SMTP id l33mr7119551ybj.280.1547069016441; Wed, 09 Jan 2019 13:23:36 -0800 (PST) Received: from localhost ([2620:10d:c091:200::7:f15b]) by smtp.gmail.com with ESMTPSA id s185sm36693021yws.69.2019.01.09.13.23.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 09 Jan 2019 13:23:35 -0800 (PST) Date: Wed, 9 Jan 2019 16:23:34 -0500 From: Johannes Weiner To: Yang Shi Cc: mhocko@suse.com, shakeelb@google.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC v3 PATCH 0/5] mm: memcontrol: do memory reclaim when offlining Message-ID: <20190109212334.GA18978@cmpxchg.org> References: <1547061285-100329-1-git-send-email-yang.shi@linux.alibaba.com> <20190109193247.GA16319@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 09, 2019 at 12:36:11PM -0800, Yang Shi wrote: > As I mentioned above, if we know some page caches from some memcgs > are referenced one-off and unlikely shared, why just keep them > around to increase memory pressure? It's just not clear to me that your scenarios are generic enough to justify adding two interfaces that we have to maintain forever, and that they couldn't be solved with existing mechanisms. Please explain: - Unmapped clean page cache isn't expensive to reclaim, certainly cheaper than the IO involved in new application startup. How could recycling clean cache be a prohibitive part of workload warmup? - Why you cannot temporarily raise the kswapd watermarks right before an important application starts up (your answer was sorta handwavy) - Why you cannot use madvise/fadvise when an application whose cache you won't reuse exits - Why you couldn't set memory.high or memory.max to 0 after the application quits and before you call rmdir on the cgroup Adding a permanent kernel interface is a serious measure. I think you need to make a much better case for it, discuss why other options are not practical, and show that this will be a generally useful thing for cgroup users and not just a niche fix for very specific situations.