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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83217ECAAD4 for ; Mon, 29 Aug 2022 10:40:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229536AbiH2KkN (ORCPT ); Mon, 29 Aug 2022 06:40:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229717AbiH2KkK (ORCPT ); Mon, 29 Aug 2022 06:40:10 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 25BF76389; Mon, 29 Aug 2022 03:40:06 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 5652233681; Mon, 29 Aug 2022 10:40:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1661769605; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YyrUyc//S6lyu1GkaA3SvkFVh044FLWZiRnNfMaJfiQ=; b=sealo4JgszYzk3Q2SF7jDXyb+wUABg85KYwx49/EUGKvkBaXX/kTf9TlfzGXDN+Mu5ulPn ZURHB3vlh8kKMdn4Y1jckgKOOqFh2+/xM4JaQVl79/OQrNHxgVezqk+h2rceWlN/QWiB8Q sucYahKq9QPP3O6pIx7HJFlTcccMynI= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 32DCF133A6; Mon, 29 Aug 2022 10:40:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id uxstCoWXDGO7SQAAMHmgww (envelope-from ); Mon, 29 Aug 2022 10:40:05 +0000 Date: Mon, 29 Aug 2022 12:40:04 +0200 From: Michal Hocko To: Yu Zhao Cc: Andrew Morton , Suren Baghdasaryan , David Rientjes , Matthew Wilcox , Johannes Weiner , Roman Gushchin , Minchan Kim , "Kirill A . Shutemov" , Andrea Arcangeli , brauner@kernel.org, Christoph Hellwig , oleg@redhat.com, David Hildenbrand , Jann Horn , Shakeel Butt , Peter Xu , John Hubbard , shuah@kernel.org, linux-kernel , Linux-MM , linux-kselftest@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH RESEND v2 2/2] mm: delete unused MMF_OOM_VICTIM flag Message-ID: References: <20220531223100.510392-1-surenb@google.com> <20220531223100.510392-2-surenb@google.com> <20220822152119.96d40c884078229ee3e6b25e@linux-foundation.org> <20220822154822.366a9e4527b748cf99d98637@linux-foundation.org> <20220822161603.9e19edfe2daaea3bf591910a@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org On Sun 28-08-22 13:50:09, Yu Zhao wrote: > On Tue, Aug 23, 2022 at 2:36 AM Michal Hocko wrote: [...] > > You cannot really make any > > assumptions about oom_reaper and how quickly it is going to free the > > memory. > > Agreed. But here we are talking about heuristics, not dependencies on > certain behaviors. Assume we are playing a guessing game: there are > multiple mm_structs available for reclaim, would the oom-killed ones > be more profitable on average? I'd say no, because I assume it's more > likely than unlikely that the oom reaper is doing/to do its work. Note > that the assumption is about likelihood, hence arguably valid. Well, my main counter argument would be that we do not really want to carve last resort mechanism (which the oom reaper is) into any heuristic because any future changes into that mechanism will be much harder to justify and change. There is a cost of the maintenance that should be considered. While you might be right that this change would be beneficial, there is no actual proof of that. Historically we've had several examples of such a behavior which was really hard to change later on because the effect would be really hard to evaluate. -- Michal Hocko SUSE Labs