Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp5128799ybh; Wed, 7 Aug 2019 01:00:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqzZk0TZ8rr6epHtCllPowjyrMen3RGcqM21o1QzdwAKFgX1IyC1sAlUyXpM2Lj1/CCV0Moa X-Received: by 2002:a65:6552:: with SMTP id a18mr6824415pgw.208.1565164820403; Wed, 07 Aug 2019 01:00:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565164820; cv=none; d=google.com; s=arc-20160816; b=zm7lwI9Toyv1U1CqvKvklrGI0587SuoCJUzWA0wQUCWTkkbKL3cr0wPCiZdzd1tu1p nCtC8E3ehhG3Lzj/KPg/3kT5z8ADS8k7u+qSHxpR1/LKymi/knFj7hDFGz0r/NCramZo HcCBJT+R0E6iauVczqiTPgCPtIatsMQNLgKhfecMImU1WFRTutHhHFGKlC4fMnhYoWK+ DCthaNs/BUxjKSkhmx0hylmWFNIoOov0jN6m/RGI4mc/ROsx4607SMoTaWqe2zsLH53c kMvKKIP0jhDTQjM//ltZCdA9GTDIX1eWQEfS5O4dcWiGlF7yy7qs7cK0Ay9hJvMYPl+9 fuyQ== 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; bh=/sjfDZd59wz700DrN89/lOB/BPsttxDiNquUxYGyhak=; b=h1BXvNP1kcFMLaOXFnGPAqUgrYScwZwzaCtUgXO+BfJgCc5PKAYMGKWrep3hfa7EWF /XkMm0s28/xlGFRNZrXQnAPfVUCJXRxbwVRS3lhxHNsg9BO8T/0HUE954/Oglev/JcuD YihLZhYNbnD2zLXNCj1Gltjw28eeueknJx4jw/sn2meyy35EXhXZKKu0hRwy/oKr05WH xYiHHSuI1R+XjbyQKAicUqmo1ueuYD7uz/JkFMLVZkvFWwKv2uwmm8OgRCK70r0IbC1y 9xWY6ev+3dIgSSy3hNZaZl9+ALQLwpz8Q6gE+TSYhBWr0qev9t3mkLjWNS9kuTbnbDWy guFQ== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c127si51564910pfc.191.2019.08.07.01.00.05; Wed, 07 Aug 2019 01:00:20 -0700 (PDT) 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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728110AbfHGH73 (ORCPT + 99 others); Wed, 7 Aug 2019 03:59:29 -0400 Received: from mx2.suse.de ([195.135.220.15]:37626 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727413AbfHGH73 (ORCPT ); Wed, 7 Aug 2019 03:59:29 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id E3C77ACC6; Wed, 7 Aug 2019 07:59:27 +0000 (UTC) Date: Wed, 7 Aug 2019 09:59:27 +0200 From: Michal Hocko To: Johannes Weiner Cc: Suren Baghdasaryan , Vlastimil Babka , "Artem S. Tashkinov" , LKML , linux-mm Subject: Re: Let's talk about the elephant in the room - the Linux kernel's inability to gracefully handle low memory pressure Message-ID: <20190807075927.GO11812@dhcp22.suse.cz> References: <20190805193148.GB4128@cmpxchg.org> <398f31f3-0353-da0c-fc54-643687bb4774@suse.cz> <20190806142728.GA12107@cmpxchg.org> <20190806143608.GE11812@dhcp22.suse.cz> <20190806220150.GA22516@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190806220150.GA22516@cmpxchg.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 06-08-19 18:01:50, Johannes Weiner wrote: > On Tue, Aug 06, 2019 at 09:27:05AM -0700, Suren Baghdasaryan wrote: [...] > > > > I'm not sure 10s is the perfect value here, but I do think the kernel > > > > should try to get out of such a state, where interacting with the > > > > system is impossible, within a reasonable amount of time. > > > > > > > > It could be a little too short for non-interactive number-crunching > > > > systems... > > > > > > Would it be possible to have a module with tunning knobs as parameters > > > and hook into the PSI infrastructure? People can play with the setting > > > to their need, we wouldn't really have think about the user visible API > > > for the tuning and this could be easily adopted as an opt-in mechanism > > > without a risk of regressions. > > It's relatively easy to trigger a livelock that disables the entire > system for good, as a regular user. It's a little weird to make the > bug fix for that an opt-in with an extensive configuration interface. Yes, I definitely do agree that this is a bug fix more than a feature. The thing is that we do not know what the proper default is for a wide variety of workloads so some way of configurability is needed (level and period). If making this a module would require a lot of additional code then we need a kernel command line parameter at least. A module would have a nice advantage that you can change your configuration without rebooting. The same can be achieved by a sysfs on the other hand. -- Michal Hocko SUSE Labs