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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,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 AF6CCC433E2 for ; Mon, 7 Sep 2020 07:26:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1DE2520757 for ; Mon, 7 Sep 2020 07:26:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1DE2520757 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 73B596B005D; Mon, 7 Sep 2020 03:26:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6EB99900002; Mon, 7 Sep 2020 03:26:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B3096B0068; Mon, 7 Sep 2020 03:26:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 449486B005D for ; Mon, 7 Sep 2020 03:26:11 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 100541EF2 for ; Mon, 7 Sep 2020 07:26:11 +0000 (UTC) X-FDA: 77235431742.10.cloud65_5004d3a270ca Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id DB98E16A0AE for ; Mon, 7 Sep 2020 07:26:10 +0000 (UTC) X-HE-Tag: cloud65_5004d3a270ca X-Filterd-Recvd-Size: 3971 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Mon, 7 Sep 2020 07:26:10 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0F480AD6B; Mon, 7 Sep 2020 07:26:10 +0000 (UTC) Date: Mon, 7 Sep 2020 09:26:08 +0200 From: Michal Hocko To: Pavel Tatashin Cc: David Hildenbrand , Vlastimil Babka , LKML , Andrew Morton , linux-mm Subject: Re: [PATCH] mm/memory_hotplug: drain per-cpu pages again during memory offline Message-ID: <20200907072608.GE30144@dhcp22.suse.cz> References: <74f2341a-7834-3e37-0346-7fbc48d74df3@suse.cz> <20200902151306.GL4617@dhcp22.suse.cz> <20200903063806.GM4617@dhcp22.suse.cz> <20200904070235.GA15277@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: DB98E16A0AE X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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 Fri 04-09-20 10:25:02, Pavel Tatashin wrote: > > Another alternative would be to enable/disable static branch only from > > users who really care but this is quite tricky because how do you tell > > you need or not? It seems that alloc_contig_range would be just fine > > with a weaker semantic because it would "only" to a spurious failure. > > Memory hotplug on the other hand really needs to have a point where > > nobody interferes with the offlined memory so it could ask for a > > stronger semantic. > > > > Yet another option would be to make draining stronger and actually > > guarantee there are no in-flight pages to be freed to the pcp list. > > One way would be to tweak pcp->high and implement a strong barrier > > (IPI?) to sync with all CPUs. Quite expensive, especially when there are > > many draining requests (read cma users because hotplug doesn't really > > matter much as it happens seldom). > > > > So no nice&cheap solution I can think of... > > I think start_isolate_page_range() should not be doing page draining > at all. It should isolate ranges, meaning set appropriate flags, but > draining should be performed by the users when appropriate: next to > lru_add_drain_all() calls both in CMA and hotplug. I disagree. The pcp draining is an implementation detail and we shouldn't bother callers to be aware of it. > Currently, the way start_isolate_page_range() drains pages is very > inefficient. It calls drain_all_pages() for every valid page block, > which is a slow call as it starts a thread per cpu, and waits for > those threads to finish before returning. This is an implementation detail. > We could optimize by moving the drain_all_pages() calls from > set_migratetype_isolate() to start_isolate_page_range() and call it > once for every different zone, but both current users of this > interface guarantee that all pfns [start_pfn, end_pfn] are within the > same zone, and I think we should keep it this way, so again the extra > traversal is going to be overhead overhead. Again this just leads to tricky code. Just look at how easy it was to break this by removing something that looked clearly a duplicate call. It is true that memory isolation usage is limited to only few usecasaes but I would strongly prefer to make the semantic clear so that we do not repeat this regressions. -- Michal Hocko SUSE Labs