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=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 291E4C43461 for ; Wed, 2 Sep 2020 15:13:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DC3BB21532 for ; Wed, 2 Sep 2020 15:13:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC3BB21532 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 6FF486B0089; Wed, 2 Sep 2020 11:13:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D5D66B008A; Wed, 2 Sep 2020 11:13:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 612DD900003; Wed, 2 Sep 2020 11:13:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4CAA96B0089 for ; Wed, 2 Sep 2020 11:13:11 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0F26D8248068 for ; Wed, 2 Sep 2020 15:13:11 +0000 (UTC) X-FDA: 77218464582.27.cave06_6311d08270a1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id A4EC43D663 for ; Wed, 2 Sep 2020 15:13:10 +0000 (UTC) X-HE-Tag: cave06_6311d08270a1 X-Filterd-Recvd-Size: 3015 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Wed, 2 Sep 2020 15:13:08 +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 AFE3CB1D1; Wed, 2 Sep 2020 15:13:08 +0000 (UTC) Date: Wed, 2 Sep 2020 17:13:06 +0200 From: Michal Hocko To: Vlastimil Babka Cc: Pavel Tatashin , LKML , Andrew Morton , linux-mm Subject: Re: [PATCH] mm/memory_hotplug: drain per-cpu pages again during memory offline Message-ID: <20200902151306.GL4617@dhcp22.suse.cz> References: <20200901124615.137200-1-pasha.tatashin@soleen.com> <20200902140851.GJ4617@dhcp22.suse.cz> <74f2341a-7834-3e37-0346-7fbc48d74df3@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74f2341a-7834-3e37-0346-7fbc48d74df3@suse.cz> X-Rspamd-Queue-Id: A4EC43D663 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 Wed 02-09-20 16:55:05, Vlastimil Babka wrote: > On 9/2/20 4:26 PM, Pavel Tatashin wrote: > > On Wed, Sep 2, 2020 at 10:08 AM Michal Hocko wrote: > >> > >> > > >> > Thread#1 - continue > >> > free_unref_page_commit > >> > migratetype = get_pcppage_migratetype(page); > >> > // get old migration type > >> > list_add(&page->lru, &pcp->lists[migratetype]); > >> > // add new page to already drained pcp list > >> > > >> > Thread#2 > >> > Never drains pcp again, and therefore gets stuck in the loop. > >> > > >> > The fix is to try to drain per-cpu lists again after > >> > check_pages_isolated_cb() fails. > >> > >> But this means that the page is not isolated and so it could be reused > >> for something else. No? > > > > The page is in a movable zone, has zero references, and the section is > > isolated (i.e. set_pageblock_migratetype(page, MIGRATE_ISOLATE);) is > > set. The page should be offlinable, but it is lost in a pcp list as > > that list is never drained again after the first failure to migrate > > all pages in the range. > > Yeah. To answer Michal's "it could be reused for something else" - yes, somebody > could allocate it from the pcplist before we do the extra drain. But then it > becomes "visible again" and the loop in __offline_pages() should catch it by > scan_movable_pages() - do_migrate_range(). And this time the pageblock is > already marked as isolated, so the page (freed by migration) won't end up on the > pcplist again. So the page block is marked MIGRATE_ISOLATE but the allocation itself could be used for non migrateable objects. Or does anything prevent that from happening? We really do depend on isolation to not allow reuse when offlining. -- Michal Hocko SUSE Labs