Received: by 2002:ac0:ada8:0:0:0:0:0 with SMTP id o37-v6csp8774imb; Mon, 2 Jul 2018 06:40:55 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLrjlT3JXSo1M00elbAlLvwjkrMZ6gBFcdFQmMrJfN1DrzmwJ8U8bDEEjbikDxWMwyrOC0Z X-Received: by 2002:a17:902:3041:: with SMTP id u59-v6mr25966162plb.208.1530538855419; Mon, 02 Jul 2018 06:40:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530538855; cv=none; d=google.com; s=arc-20160816; b=s98TUJtEHRgPdltvW4T4CW2G5Y3CE6bwx90ef2TnRHX6kcoRmBn2BdnMAf2aaJAtUz 4UPaHdUJ6lFrH71yAPMJ0iiROJnvx0YITkcJejNFHkdgpTpMg5qM2cIxNqITAQg2uoOy kBjXLC6Suk9SF4BpjUJkj6E0TI1+2PydlRzev/V7nRmyqHromiR2meqafa8mpvOzcEC0 VDox5yhJr75A9f1JoURlysgmEKODYZae1pDjwthyf75si50Z6m9uZCrUc+i3nCK2Aloi vldrbBpnXTp0KWMhHeH3qEFBF/YuHNsYXcE4/UQ+QaZ7a7fQvW7lTZNK8kNIMZAptogb xiMw== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=VBaCsy4MbCKVGsYoVIdaeixJVobAR5EcLvoSxcROFqE=; b=fpO3aUhvNNhFJt/pm3R+djzIfyJMu8vhiR4s180DOp0HIpNdWdAYH88ElVK2KHF8mN WvgR0q7AD+f8TJxNiW6eiMcj7bixTkrh/uI4NdyOp4QqJMkTPyBoKvHaopfNxJ7CLFtA q51Iud1URWWvuplVCvVn06JRiaH4Ur9g/L56qccPwOx/zTKc1Rmli7rTMWZntxRHpbZf /wFI5NX2wELPAQkWfGkndfVNIyU5iyMqpMGmo1aQjuFeVnezmXZfXfAUdUpRFF5zmDc9 gvLo1sI9e5qufRxoSd/XW6+l03HW4upNHQ2bSaiKE06KXzknNcXNv1rXAm+Lpnx2NsgT vagw== 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 m3-v6si13861774pgu.237.2018.07.02.06.40.40; Mon, 02 Jul 2018 06:40:55 -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 S1752176AbeGBNj4 (ORCPT + 99 others); Mon, 2 Jul 2018 09:39:56 -0400 Received: from mx2.suse.de ([195.135.220.15]:45966 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751912AbeGBNjz (ORCPT ); Mon, 2 Jul 2018 09:39:55 -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 031C1AD12; Mon, 2 Jul 2018 13:39:54 +0000 (UTC) Date: Mon, 2 Jul 2018 15:39:53 +0200 From: Michal Hocko To: Yang Shi Cc: willy@infradead.org, ldufour@linux.vnet.ibm.com, akpm@linux-foundation.org, peterz@infradead.org, mingo@redhat.com, acme@kernel.org, alexander.shishkin@linux.intel.com, jolsa@redhat.com, namhyung@kernel.org, tglx@linutronix.de, hpa@zytor.com, linux-mm@kvack.org, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC v3 PATCH 0/5] mm: zap pages with read mmap_sem in munmap for large mapping Message-ID: <20180702133953.GV19043@dhcp22.suse.cz> References: <1530311985-31251-1-git-send-email-yang.shi@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1530311985-31251-1-git-send-email-yang.shi@linux.alibaba.com> 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 Sat 30-06-18 06:39:40, Yang Shi wrote: > > Background: > Recently, when we ran some vm scalability tests on machines with large memory, > we ran into a couple of mmap_sem scalability issues when unmapping large memory > space, please refer to https://lkml.org/lkml/2017/12/14/733 and > https://lkml.org/lkml/2018/2/20/576. > > > History: > Then akpm suggested to unmap large mapping section by section and drop mmap_sem > at a time to mitigate it (see https://lkml.org/lkml/2018/3/6/784). > > V1 patch series was submitted to the mailing list per Andrew’s suggestion > (see https://lkml.org/lkml/2018/3/20/786). Then I received a lot great feedback > and suggestions. > > Then this topic was discussed on LSFMM summit 2018. In the summit, Michal Hock > suggested (also in the v1 patches review) to try "two phases" approach. Zapping > pages with read mmap_sem, then doing via cleanup with write mmap_sem (for > discussion detail, see https://lwn.net/Articles/753269/) The cover letter should really describe your approach to the problem. But there is none here. -- Michal Hocko SUSE Labs