Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp268560imm; Wed, 11 Jul 2018 02:01:03 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcn4coK2aExn1Cv9WRD/pKKqrntV/YD31XmtmxTB//DRbwIf9c90ocGWe5cQ3W6NcvRh6l9 X-Received: by 2002:a17:902:5501:: with SMTP id f1-v6mr27752408pli.108.1531299663443; Wed, 11 Jul 2018 02:01:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531299663; cv=none; d=google.com; s=arc-20160816; b=qID6PPM0OyATS1iL5sdG0BmZDBnxHVOP7uLCgjao4KJw7tUtWH5qc/RF1aUbC4cihv EeXGk/7SMdSmFKKkoIeQZ2ms1sr40ANdn3+cKfbptSfPidCcCHsguhwRnhVprpChI4im Sfcm32aJMDw1knWs3BS0SPsvEL3bHgaM258n67W5X/rcN1VIRzkjsAlu8p83yPJ2t7xz 494iGcEll3HCRydJaBGXDSRi6I5VV12DdEAIzbUFhto+nGfy0jqjK4ZtKhSooTqr6oIm Nmtw3TlCoiXep5YAbNQorMuOarbseq6CspXLZXIF30DXmTSiQUgbHmQhE/y4Tbibg3nO KwTg== 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=awU3eLd405isqvPMJ9iKiJau7RMQrJ/W0j1Pi4uqvek=; b=DNpV4QrDVO0p+xHZRiugra/O+WjZAeZMhwhYR5pa2ay4+TxiRJp0G4XcUdyPL6WC/k +koacM/dCITKtldz+j0WaSmcMggpTPlOHiZVe59uqA5yNrnVMiv4QJOGiVu+qWqXcWKQ rD9RRS7Z3GGBIrxyn6H0sO/1vF0wF9TlAwuQbpECNTqmTtlERabK23o4LgpRZvRG8wzc N0SZPVqE/PZS9YWvHSgDap5/h4ZDJkhQkeZYcX/7KPw6Li87kM4lMYa05zmFqMAyPjVL 8Ug6iA28Lxgu89l104WR23GY1L3sfjNvU6I+xbrlqQDNjeWCK4UJ1EhbVYzB3wF9BJN7 W39g== 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 f1-v6si21273570plm.375.2018.07.11.02.00.39; Wed, 11 Jul 2018 02:01:03 -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 S1732413AbeGKJC1 (ORCPT + 99 others); Wed, 11 Jul 2018 05:02:27 -0400 Received: from mx2.suse.de ([195.135.220.15]:60040 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726480AbeGKJC1 (ORCPT ); Wed, 11 Jul 2018 05:02:27 -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 12113AE9F; Wed, 11 Jul 2018 08:59:10 +0000 (UTC) Date: Wed, 11 Jul 2018 10:59:08 +0200 From: Michal Hocko To: David Rientjes Cc: Andrew Morton , Tetsuo Handa , linux-mm@kvack.org, LKML Subject: Re: [PATCH] mm, oom: remove sleep from under oom_lock Message-ID: <20180711085908.GC20050@dhcp22.suse.cz> References: <20180709074706.30635-1-mhocko@kernel.org> <20180710094341.GD14284@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 10-07-18 14:12:28, David Rientjes wrote: > On Tue, 10 Jul 2018, David Rientjes wrote: > > > I think it's better, thanks. However, does it address the question about > > why __oom_reap_task_mm() needs oom_lock protection? Perhaps it would be > > helpful to mention synchronization between reaping triggered from > > oom_reaper and by exit_mmap(). > > > > Actually, can't we remove the need to take oom_lock in exit_mmap() if > __oom_reap_task_mm() can do a test and set on MMF_UNSTABLE and, if already > set, bail out immediately? I think we do not really depend on oom_lock anymore in __oom_reap_task_mm. The race it was original added for (mmget_not_zero vs. exit path) is no longer a problem. I didn't really get to evaluate it deeper though. There are just too many things going on in parallel. Tetsuo was proposing some patches to remove the lock but those patches had some other problems. If we have a simple patch to remove the oom_lock from the oom reaper then I will review it. I am not sure I can come up with a patch myself in few days. -- Michal Hocko SUSE Labs