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 X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D3EF9C433E0 for ; Tue, 7 Jul 2020 17:03:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 791D620672 for ; Tue, 7 Jul 2020 17:03:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="OOGSMxRh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 791D620672 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AE6A76B0088; Tue, 7 Jul 2020 13:03:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A96466B0092; Tue, 7 Jul 2020 13:03:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95F136B0093; Tue, 7 Jul 2020 13:03:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0121.hostedemail.com [216.40.44.121]) by kanga.kvack.org (Postfix) with ESMTP id 807346B0088 for ; Tue, 7 Jul 2020 13:03:42 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id EFF34824934B for ; Tue, 7 Jul 2020 17:03:41 +0000 (UTC) X-FDA: 77011901442.12.teeth34_5a05e2826eb6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 9CF991800F596 for ; Tue, 7 Jul 2020 17:03:03 +0000 (UTC) X-HE-Tag: teeth34_5a05e2826eb6 X-Filterd-Recvd-Size: 6174 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Tue, 7 Jul 2020 17:03:02 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id q7so37527860ljm.1 for ; Tue, 07 Jul 2020 10:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wWtqhQ1RMjRjpz8jm0pj/37FDxLQZ8+O9P8GTDhdm3U=; b=OOGSMxRhcoi7zXdpuHNOLamUQAGE/1dJvH57Oa2F7Dps70haKJ/iXRSThoOAl+4HDt fxUVYRoUA639HuyMtcTbnCZxTWFpur1enHcLY1+ZB/a92EhFjm5MZYW7Oq0HKUalGr6i dD8QbODR2513m2AsU5nK7RzbWo62rfxGu9YG6A3Wl8BAp1/uN7OtGoeinAkh7R6J850w oN8H0zGgpLNnOwE+o/kncGTkpwg8SwGs71l4ROffLmqLjjwkmXF5IDwDV+b7x9zm5WLk lkwKAiOezp0G9ojA7UL4URciZn3b0RSBk8z4v+JBUZUqnUvEMklVvRgfZAm8zqvahHrw 1nwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wWtqhQ1RMjRjpz8jm0pj/37FDxLQZ8+O9P8GTDhdm3U=; b=bQNM9JpQ3HjwhLOSkhy0No2Jz3nl+a0V2YgQdqOWY+fxYg3pl0lEPHuckixZ4TX+cU cIUDKo8KeIatnazm4kwEHmkYmwp2ys1Yvq1tco9HZLywt0yFVXD4KHUZCSMM8DXO1bxK qGNWlji0h2PTcXcjTvWQ+Yr+3Z1MAUwjPYfbm9UdDC9ZcacpLTMFNziyyLDfNJzbVYQE rN+IAecPbeYayfCIB1L/HlvPEtROzCGU25Lm//H1JKoAWKUcBQUMroy2SeGOgSbOFFGF 7ZsCDj4RkLCPKpXL2GEL41LbUH6USZCjSS7i2mu1R2cJQu4/gjzjA6oHQyvPgR+6G2A9 f3Ww== X-Gm-Message-State: AOAM533UO7NBRiWXerpDQ8SZoTP0KTZn0b07/5qZ/Q0v2lxV2ZPt5ZWr oBSG6ePhqX8WB0+eWvkGeoWeru4OCR8NW1740VrBZg== X-Google-Smtp-Source: ABdhPJw4yPDo5/19AZW3fu7bt8YjrigxHvmkSzn5gvdi7ni0uhX8fx1MsMUD4Yqp646UBmzEk0B7lJQWf/IXp7CS3IE= X-Received: by 2002:a05:651c:10f:: with SMTP id a15mr29464307ljb.192.1594141381178; Tue, 07 Jul 2020 10:03:01 -0700 (PDT) MIME-Version: 1.0 References: <20200702152222.2630760-1-shakeelb@google.com> <20200703063548.GM18446@dhcp22.suse.cz> <20200707121422.GP5913@dhcp22.suse.cz> In-Reply-To: <20200707121422.GP5913@dhcp22.suse.cz> From: Shakeel Butt Date: Tue, 7 Jul 2020 10:02:50 -0700 Message-ID: Subject: Re: [RFC PROPOSAL] memcg: per-memcg user space reclaim interface To: Michal Hocko Cc: Johannes Weiner , Roman Gushchin , Yang Shi , David Rientjes , Greg Thelen , Andrew Morton , Linux MM , LKML , Cgroups Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 9CF991800F596 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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, Jul 7, 2020 at 5:14 AM Michal Hocko wrote: > > On Fri 03-07-20 07:23:14, Shakeel Butt wrote: > > On Thu, Jul 2, 2020 at 11:35 PM Michal Hocko wrote: > > > > > > On Thu 02-07-20 08:22:22, Shakeel Butt wrote: > > > [...] > > > > Interface options: > > > > ------------------ > > > > > > > > 1) memcg interface e.g. 'echo 10M > memory.reclaim' > > > > > > > > + simple > > > > + can be extended to target specific type of memory (anon, file, kmem). > > > > - most probably restricted to cgroup v2. > > > > > > > > 2) fadvise(PAGEOUT) on cgroup_dir_fd > > > > > > > > + more general and applicable to other FSes (actually we are using > > > > something similar for tmpfs). > > > > + can be extended in future to just age the LRUs instead of reclaim or > > > > some new use cases. > > > > > > Could you explain why memory.high as an interface to trigger pro-active > > > memory reclaim is not sufficient. Also memory.low limit to protect > > > latency sensitve workloads? > > > > Yes, we can use memory.high to trigger [proactive] reclaim in a memcg > > but note that it can also introduce stalls in the application running > > in that memcg. Let's suppose the memory.current of a memcg is 100MiB > > and we want to reclaim 20MiB from it, we can set the memory.high to > > 80MiB but any allocation attempt from the application running in that > > memcg can get stalled/throttled. I want the functionality of the > > reclaim without potential stalls. > > It would be great if the proposal mention this limitation. > Will do in the next version. > > The memory.min is for protection against the global reclaim and is > > unrelated to this discussion. > > Well, I was talkingg about memory.low. It is not meant only to protect > from the global reclaim. It can be used for balancing memory reclaim > from _any_ external memory pressure source. So it is somehow related to > the usecase you have mentioned. > For the uswapd use-case, I am not concerned about the external memory pressure source but the application hitting its own memory.high limit and getting throttled. > What you consider a latency sensitive workload could be protected from > directly induced reclaim latencies. You could use low events to learn > about the external memory pressure and update your protection to allow > for some reclaim. I do understand that this wouldn't solve your problem > who gets reclaimed and maybe that is the crux on why it is not > applicable but that should really be mentioned explicitly. > The main aim for the proactive reclaim is to not cause an external memory pressure. The low events can be another source of information to tell the system level situation to the 'Memory Overcommit Controller'. So, I see the low events as complementary, not the replacement for the reclaim interface. BTW by "low events from external memory pressure" am I correct in understanding that you meant an unrelated job reclaiming and triggering low events on a job of interest. Or do you mean to partition a job into sub-jobs and then use the low events between these sub-jobs somehow?