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=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 C9A95C83003 for ; Wed, 29 Apr 2020 11:43:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 911C12074A for ; Wed, 29 Apr 2020 11:43:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 911C12074A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1297E8E0005; Wed, 29 Apr 2020 07:43:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0DB3E8E0001; Wed, 29 Apr 2020 07:43:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F0AA68E0005; Wed, 29 Apr 2020 07:43:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0196.hostedemail.com [216.40.44.196]) by kanga.kvack.org (Postfix) with ESMTP id D972A8E0001 for ; Wed, 29 Apr 2020 07:43:33 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A426345A3 for ; Wed, 29 Apr 2020 11:43:33 +0000 (UTC) X-FDA: 76760707506.07.shirt65_594311a60153e X-HE-Tag: shirt65_594311a60153e X-Filterd-Recvd-Size: 4148 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Wed, 29 Apr 2020 11:43:33 +0000 (UTC) Received: by mail-wm1-f49.google.com with SMTP id u16so1658037wmc.5 for ; Wed, 29 Apr 2020 04:43:33 -0700 (PDT) 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; bh=vevoXjwrhXkj2nIiMSFHvSIkFN/LcgtuZhtgDAeX9Ho=; b=fJPQ3hwF8eBb6ze8V49ukZEBCSDIxShrIefl3NOc4vNBrAsyM6xXua8edTjGVhgIhd SpGTZZrNWILfe2pxMdweJHU29JDCLK5C8PQJbrTC0sGdrANZ+mudkZw2ICBkYGTfm299 h/vBPVKU/0nuVKAo5RwrBrp3nH24elyyKdmpLfpVECgHTDDaJBIi7VQfQNyQVKF+GvSG SZd1YA8Bi4wYEJeZX1n8onYKlBCwZWdC/JEsQ1HF0/GBMhdqCnIYPmm0tcJwyx1PEDOc PW5oJBB7JWwMQg3JmzPMK8C44X+GjngWvpdMMb73GsDwCMgto7V11hI/vclo/jg38Pg3 ZZUw== X-Gm-Message-State: AGi0PuY3JFfulbFnGGhM5XONSdJQJ9kMa9/7m04dQVeYR5QPAKFdLM2j qFQ0C6H3OEnlvL+/QLdrUYU= X-Google-Smtp-Source: APiQypJQvLdxuHCouxvtvxUtGgJlISAl5jQQE/s/6hextuemczADwYjrAHODiBlHWhpH8mpep7fiaA== X-Received: by 2002:a05:600c:2945:: with SMTP id n5mr2815015wmd.148.1588160612267; Wed, 29 Apr 2020 04:43:32 -0700 (PDT) Received: from localhost (ip-37-188-130-62.eurotel.cz. [37.188.130.62]) by smtp.gmail.com with ESMTPSA id z10sm30564879wrg.69.2020.04.29.04.43.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Apr 2020 04:43:31 -0700 (PDT) Date: Wed, 29 Apr 2020 13:43:29 +0200 From: Michal Hocko To: Tetsuo Handa Cc: Vlastimil Babka , David Rientjes , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mel Gorman Subject: Re: [patch] mm, oom: stop reclaiming if GFP_ATOMIC will start failing soon Message-ID: <20200429114329.GB28637@dhcp22.suse.cz> References: <20200425172706.26b5011293e8dc77b1dccaf3@linux-foundation.org> <20200427133051.b71f961c1bc53a8e72c4f003@linux-foundation.org> <28e35a8b-400e-9320-5a97-accfccf4b9a8@suse.cz> <31f1f84d-c5fe-824b-3c28-1a9ad69fcae5@suse.cz> <20200429090437.GX28637@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed 29-04-20 19:45:07, Tetsuo Handa wrote: > On 2020/04/29 18:04, Michal Hocko wrote: > > Completely agreed! The in kernel OOM killer is to deal with situations > > when memory is desperately depleted without any sign of a forward > > progress. If there is a reclaimable memory then we are not there yet. > > If a workload can benefit from early oom killing based on response time > > then we have facilities to achieve that (e.g. PSI). > > Can PSI work even if userspace process cannot avoid reclaimable memory > allocations (e.g. page fault, file read) is already stalling? The userspace itself would have to be careful and use mlock of course. But collecting the psi information itself should be pretty independent on memory allocations as monitoring the system memory state is one of the main usecases. > I'm not sure > whether PSI allows responding quickly enough to "keep reclaimable memory > allocations not to reclaim" despite there is still reclaimable memory... PSI is supposed to monitor time spent in the memory allocator (among other things) and report the tendency. This should be a sufficient metric to judge that a large part of the userspace is not making forward progress. -- Michal Hocko SUSE Labs