Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp538224pxk; Wed, 2 Sep 2020 08:15:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyUWxfXuV4b9OOVYO3B5qPMV6Xgda6QVcJzrmLOj8+gbL/an4lOCFQ9VCRGe5ENSkI+pdYL X-Received: by 2002:a05:6402:1d05:: with SMTP id dg5mr525724edb.67.1599059726457; Wed, 02 Sep 2020 08:15:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599059726; cv=none; d=google.com; s=arc-20160816; b=1HOmoNgP1cLg4+zE4rVTXtbkOguQZIrEjdutGJGVYbr9bdrss332xpBMPQ9VL/tGSn F8Pf6m0+s3OonJQSmo4QR5nKIx8jnZbgXfkl4/Gk4rkWO0rNWZ1aY7tYbZPLIrV3TI8g K3NIQBk6iCYIvbBVVnSqbR+N3exooUDt7fccZ/Kt/t/agM3xQ68/4bmgVLxT4ENccHd/ fJMAfi4tOcrWlkXLAdalvzXKxVsLcBTcavYu0rGsu9Gwc1oQ4/ZSleyXBeCgdq9cFfGF 2+xg+eEw7k9vGa5BgWTMQ2L02idPFng+WwTZsal/UqMz7MIqsXsiYcL9wboJzkv4dShq NIJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=hSMs+Szq/kY/J8NKSZGfvBII1wsn6VRs76my8apqEMI=; b=NEqXtaqQFpHxzEE7+LbRpBc1e9knPGwad8bjozeSStqGyAsTJkmfJqYz9m2i5sYx7O ga8yL0I/bP2oTPTgnbpkTZ9JYI05UIVHyexNTX7V7zdkBPixByEVINyDcRsC8gDNlXa5 gaBYjNUnKVut5lpI9Af+VXuyhQP5y1CVPJu+GuBckYJyoS4s6rfI5/k7KCFJjH/DydHz 0yK2H+VMkrCB0+9s0nX96JqvU1GoyAj83KxaeFmYEu/vSmwTjvVllAFuU4YA1cjRiGLk z6jL90jY6WQT0x6n/9kE55axtTVKFTGU4nIjAuA0MfV6tnCoMoKcl3EWr8BJTNC5SYeO KbrA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q20si2898297ejb.45.2020.09.02.08.15.03; Wed, 02 Sep 2020 08:15:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728073AbgIBPOB (ORCPT + 99 others); Wed, 2 Sep 2020 11:14:01 -0400 Received: from mx2.suse.de ([195.135.220.15]:32808 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726871AbgIBPNI (ORCPT ); Wed, 2 Sep 2020 11:13:08 -0400 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> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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