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=-5.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 1F1F7C2BD11 for ; Wed, 2 Sep 2020 14:49:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C45D4207D3 for ; Wed, 2 Sep 2020 14:49:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C45D4207D3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 566B06B0062; Wed, 2 Sep 2020 10:49:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 517BE900004; Wed, 2 Sep 2020 10:49:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 454AF6B008A; Wed, 2 Sep 2020 10:49:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0116.hostedemail.com [216.40.44.116]) by kanga.kvack.org (Postfix) with ESMTP id 323976B0062 for ; Wed, 2 Sep 2020 10:49:23 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C947F283C for ; Wed, 2 Sep 2020 14:49:22 +0000 (UTC) X-FDA: 77218404564.05.key40_17101d4270a1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 9E43E18017886 for ; Wed, 2 Sep 2020 14:49:22 +0000 (UTC) X-HE-Tag: key40_17101d4270a1 X-Filterd-Recvd-Size: 2518 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Wed, 2 Sep 2020 14:49:22 +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 849C4ACBA; Wed, 2 Sep 2020 14:49:21 +0000 (UTC) Subject: Re: [PATCH] mm/memory_hotplug: drain per-cpu pages again during memory offline To: Pavel Tatashin , Michal Hocko Cc: LKML , Andrew Morton , linux-mm , Mel Gorman References: <20200901124615.137200-1-pasha.tatashin@soleen.com> <20200902140116.GI4617@dhcp22.suse.cz> <20200902141057.GK4617@dhcp22.suse.cz> From: Vlastimil Babka Message-ID: Date: Wed, 2 Sep 2020 16:49:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 9E43E18017886 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 9/2/20 4:31 PM, Pavel Tatashin wrote: >> > > The fix is to try to drain per-cpu lists again after >> > > check_pages_isolated_cb() fails. >> >> Still trying to wrap my head around this but I think this is not a >> proper fix. It should be the page isolation to make sure no races are >> possible with the page freeing path. >> > > As Bharata B Rao found in another thread, the problem was introduced > by this change: > c52e75935f8d: mm: remove extra drain pages on pcp list > > So, the drain used to be tried every time with lru_add_drain_all(); > Which, I think is excessive, as we start a thread per cpu to try to > drain and catch a rare race condition. With the proposed change we > drain again only when we find such a condition. Fixing it in > start_isolate_page_range means that we must somehow synchronize it > with the release_pages() which adds costs to runtime code, instead of > to hot-remove code. Agreed. Isolation was always racy wrt freeing to pcplists, and it was simply acceptable to do some extra drains if needed. Removing that race would be indeed acceptable only if it didn't affect alloc/free fastpaths. > Pasha >