Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1287684ybt; Tue, 7 Jul 2020 11:55:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz1tXLLmDuTdozugshBMNPkoIBVSfPJyXseKBviyZGRGR/UJZYn3wNp7geZiPOyhNPZvPTC X-Received: by 2002:a17:906:f911:: with SMTP id lc17mr50413273ejb.330.1594148144611; Tue, 07 Jul 2020 11:55:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594148144; cv=none; d=google.com; s=arc-20160816; b=HvavuhnRKwKafCZXmzlB/nTVLU28+NlGGFHUcUl+x4Z+5cL2QBzIpJN07AHWBuG30X wdO0zf/bkE4s8TtYRIm3IB1yxp4TdtauiJwHkPdVqhgKKLmqFC9QcZPp4y14odFSNVlm YIPpnhQrOVaPP/ArPAgHXkF2XygZXlsZCiGK+dWl1u0oVTBrnGuSrlcSYUW6POZYkjnK 43jJIErsn4YaTx0SakfKp1tw5XcuQAmZJlmVMDqYkyQcTYOFFsw3hCkInIZZqJUtPkt4 ivK1msJV/0cw/aB7mxbecX3vD5WSTv1o/Bmm87G8i6FSL9/Ll4JZHpr05TG9tCGOnlZa Vmyw== 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=mxUeGdy8xixT3qR6TxhpxqIaXyQxpW6SR0YnzaRkS0E=; b=STgPcOjN+CWcIPn7Z06/vZmntUl8bzoDXruLXRfFnpW9tjMEUd4TY9u6c+sZ6hMy13 xigw6SlRWt4ZBJVoGfKMyXVllCm9Yb9uMok4yTgvoEHkhfosxBw+TglCwLOSSwLuKSLW ZVMHxdf7J8KQNJP13T4SJ08weuiKg2nAuYEu78OnnP0iqmP7Ol4yCDHW2wNyrQdtwUfA /mY56GiwWT4NL/TaonATigAOLpBdl1sDQHfUS/2ss5xG7z0mKcEWi7wNvSeJLpNIC1IY 50Yb5n4DlTLOP0rFO45UKDbhaQv9DECPZPt+CstOFzNjQ+O+la5sBMtMNDPTo6okMXpk SPZQ== 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c10si15552708ejs.1.2020.07.07.11.55.21; Tue, 07 Jul 2020 11:55:44 -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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728297AbgGGSzH (ORCPT + 99 others); Tue, 7 Jul 2020 14:55:07 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:37362 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728029AbgGGSzH (ORCPT ); Tue, 7 Jul 2020 14:55:07 -0400 Received: by mail-wm1-f68.google.com with SMTP id o2so202294wmh.2 for ; Tue, 07 Jul 2020 11:55:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=mxUeGdy8xixT3qR6TxhpxqIaXyQxpW6SR0YnzaRkS0E=; b=cE059tBp6tP/biRonC9H6F7xK7adZMYTvssfLnXW1r0zVF3Z9W2sQZy+pOjvq6FSoC ETx5YyXbb7ad4skddCvaHz2qImyhfjBLEgiqekZnMNnurD2QLzzCu2mTbEnfqbv08j/1 RN1ofgfjgoDBX4EHKSZSY8HY1izgYqAox7F/9kb7JHZOSYxcpKXMki4PLKjyA4wSgB2o /fIBO0RnmuWZN0r0GqrKuyhL1oL+uxhrlYT4z99DfwN+z76J5XUzZfA0klScCCK7kHtz 9OhMYtSq3vbmrYE0z/OvZoQ22gOclHGhhyjl411l4KwD0YJR2smA+X57F9nHm7P9k04B QFbA== X-Gm-Message-State: AOAM531efZZ94ViLyeelNM4GoDEVMcAjujZ6MEFwVu7VLQSymTvvtMBN NnMLKL6ontlnhRFQPai9ljo= X-Received: by 2002:a05:600c:281:: with SMTP id 1mr5683217wmk.143.1594148105262; Tue, 07 Jul 2020 11:55:05 -0700 (PDT) Received: from localhost (ip-37-188-179-51.eurotel.cz. [37.188.179.51]) by smtp.gmail.com with ESMTPSA id b62sm2319785wmh.38.2020.07.07.11.55.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2020 11:55:04 -0700 (PDT) Date: Tue, 7 Jul 2020 20:55:03 +0200 From: Michal Hocko To: Vlastimil Babka Cc: js1304@gmail.com, Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@lge.com, Christoph Hellwig , Roman Gushchin , Mike Kravetz , Naoya Horiguchi , Joonsoo Kim Subject: Re: [PATCH v4 10/11] mm/memory-failure: remove a wrapper for alloc_migration_target() Message-ID: <20200707185503.GY5913@dhcp22.suse.cz> References: <1594107889-32228-1-git-send-email-iamjoonsoo.kim@lge.com> <1594107889-32228-11-git-send-email-iamjoonsoo.kim@lge.com> <20200707114829.GL5913@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 07-07-20 17:03:50, Vlastimil Babka wrote: > On 7/7/20 1:48 PM, Michal Hocko wrote: > > On Tue 07-07-20 16:44:48, Joonsoo Kim wrote: > >> From: Joonsoo Kim > >> > >> There is a well-defined standard migration target callback. Use it > >> directly. > >> > >> Signed-off-by: Joonsoo Kim > >> --- > >> mm/memory-failure.c | 18 ++++++------------ > >> 1 file changed, 6 insertions(+), 12 deletions(-) > >> > >> diff --git a/mm/memory-failure.c b/mm/memory-failure.c > >> index 609d42b6..3b89804 100644 > >> --- a/mm/memory-failure.c > >> +++ b/mm/memory-failure.c > >> @@ -1677,16 +1677,6 @@ int unpoison_memory(unsigned long pfn) > >> } > >> EXPORT_SYMBOL(unpoison_memory); > >> > >> -static struct page *new_page(struct page *p, unsigned long private) > >> -{ > >> - struct migration_target_control mtc = { > >> - .nid = page_to_nid(p), > >> - .gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL, > >> - }; > >> - > >> - return alloc_migration_target(p, (unsigned long)&mtc); > >> -} > >> - > >> /* > >> * Safely get reference count of an arbitrary page. > >> * Returns 0 for a free page, -EIO for a zero refcount page > >> @@ -1793,6 +1783,10 @@ static int __soft_offline_page(struct page *page) > >> const char *msg_page[] = {"page", "hugepage"}; > >> bool huge = PageHuge(page); > >> LIST_HEAD(pagelist); > >> + struct migration_target_control mtc = { > >> + .nid = NUMA_NO_NODE, > >> + .gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL, > >> + }; > > > > Is NUMA_NO_NODE really intended here? The original code has preferred to > > stay on the same node. > > The alloc_migration_target() interprets NUMA_NO_NODE as a request to call > page_to_nid(), so we don't need these thin wrappers that do just that. I have > suggested this in v3 review and it's mentioned in 06/11. Ohh, right. I just lost that piece of information on the way. It wouldn't hurt to keep page_to_nid here for readability though. -- Michal Hocko SUSE Labs