Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp817069imm; Wed, 8 Aug 2018 06:18:44 -0700 (PDT) X-Google-Smtp-Source: AA+uWPxs7tsPCU6n5BpDq+rurcc3gpfFzH0lemrl1ER4fdZ1/Xj06RWQYbdSkH5tyse5JGfBWRQV X-Received: by 2002:aa7:83cd:: with SMTP id j13-v6mr2969123pfn.236.1533734324379; Wed, 08 Aug 2018 06:18:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533734324; cv=none; d=google.com; s=arc-20160816; b=aVUaAsn82r2dYJzzsQajvP+45W9Wi16tH4ZFctzHjiItZyYUfV3Xp/+K+ZEnyQ4Ws4 zg35Y7Z6G5iXEbE0fxvwRikFjvHlqDSFKV/tPzfzLbOL8jRpp+Funrc1w/SgRsFZB0bD cEcvABlU1tkKKLe512JMRl2oDvT6SZ3lZccl51E+IZ3JFBZ9eHTXlXLmNdb2hQ+PoNmT Y6UebkKu2s8qpIZH92+HSkXWy1dmvlrwGqn5LnQGLAUhnbqNbKfnhQHqo/m6jVmmSNz+ Ygzdyy39izlgCIkzXDkxAGfW9hWocpQaEK22Y0mq9Y8QjyWxPglOIPA5KvT3f+1FVtv7 65OA== 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:arc-authentication-results; bh=2wEvylaXu9WUR4Tz9UjalszM029ZLdFeiZrAqB41gC8=; b=gjustpGmhu+D5fiaUreVmUKSorjEWyqTQ6nBqr/ZjtEVx8Qqq4mCVFS1Kopk1opyV/ rLCeV1mk7+rS9SDpqe/KPxhOqbF6lRVZ1HbwHlis1bintsVJ+OZZA1TThWiMiDM0D8vJ aCMAnvhIX5/LLRclbNUkiqrevgozeljgVEkbvHjDc+7amakgPFONKe483KNKy21ATbN3 SEy21YoZxeeCl1TLvgAE6UybLWAhNX+eTAzjbNUfaOy2Hc7H5lPDm+Ep2njL2t1RbR8i G2Yh3zGoV+IMwwA13nK4WLPGTjF/wcOliPzZk6nrFCMlmEn1XnDkOdITqwCLuKOcSlDJ bOtw== 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 x1-v6si3432401plv.26.2018.08.08.06.18.29; Wed, 08 Aug 2018 06:18:44 -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 S1727303AbeHHPgi (ORCPT + 99 others); Wed, 8 Aug 2018 11:36:38 -0400 Received: from mx2.suse.de ([195.135.220.15]:41622 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726971AbeHHPgi (ORCPT ); Wed, 8 Aug 2018 11:36:38 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id AEEB1AF31; Wed, 8 Aug 2018 13:16:58 +0000 (UTC) Date: Wed, 8 Aug 2018 15:16:58 +0200 From: Michal Hocko To: Tetsuo Handa Cc: Johannes Weiner , Andrew Morton , Vladimir Davydov , linux-mm@kvack.org, Greg Thelen , Dmitry Vyukov , LKML , David Rientjes Subject: Re: [PATCH] memcg, oom: be careful about races when warning about no reclaimable task Message-ID: <20180808131658.GP27972@dhcp22.suse.cz> References: <20180807072553.14941-1-mhocko@kernel.org> <863d73ce-fae9-c117-e361-12c415c787de@i-love.sakura.ne.jp> <20180807201935.GB4251@cmpxchg.org> <1308e0bd-e194-7b35-484c-fc18f493f8da@i-love.sakura.ne.jp> <9cea37c8-ab90-2fdf-395c-efe52ff07072@i-love.sakura.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9cea37c8-ab90-2fdf-395c-efe52ff07072@i-love.sakura.ne.jp> 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 Wed 08-08-18 21:57:13, Tetsuo Handa wrote: [...] > Also, before the OOM reaper was introduced, we waited until TIF_MEMDIE is > cleared from the OOM victim thread. Compared to pre OOM reaper era, giving up > so early is certainly a regression. We did clear TIF_MEMDIE flag after mmput() in do_exit so this was not a silver bullet either. Any reference on the mm_struct would lead to a similar problem. So could you please stop making strong stamements and start being reasonable? Yeah, this is racy. Nobody is claiming otherwise. All we are trying to say is that this area is full of dragons and before we start making it more complicating by covering weird cornercases we really need to see that those corner cases happen in real workloads. Otherwise we end up with a unmaintainable and fragile mess. And more importantly this is _not_ what this patch is trying to address so please do not go tangent again. I really do not know how to send this simply message to you. I have tried so many times before. -- Michal Hocko SUSE Labs