Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2950014imm; Thu, 24 May 2018 19:43:42 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo69PC69B9WGgRuYBaYXqUl/eCvRtzOQCeUryX8gWMo99XQguWiod+XRocqbG3ONoZW8kb7 X-Received: by 2002:a62:e211:: with SMTP id a17-v6mr597995pfi.126.1527216222850; Thu, 24 May 2018 19:43:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527216222; cv=none; d=google.com; s=arc-20160816; b=0TBMFNPJfYNMTnwC5rjVtMmUMsLVVrW/OEO2UHeksAA6Z1BnvqSj7DJzuidaZkKCEo u+S8ZZKNrxYPnS1V/U0GDZ4bZSL8UjFIQUDbYwwGy98QPOj+s3bN9MU1cqXVvoXyQzQy bPv99A5a9AKC/WtKhoTXv8Kn4DczxWPZPIZV8sFxp1YNbEZBrksicJV0lGhxXyNqn5UG h2u7kmSGBZmTLv7frxmenDKlvi8BZKLF+/1U/5kiwDpNEMlj3R/wEkSFhBHe/KwJnQBN MiF55KQ8JvMmCB/0ao+aDsqYIdgCKVDS9v0ota+IfFPcF3D8D0BXB/4Mbb8g4LH34GE1 vYcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject :arc-authentication-results; bh=pb/CFdhVfCuApTjYwY5vtWSJlRoJo2CP4nd1T5uGXg4=; b=uzp947YnNgRUEOP/gnGJLBzA6enpGDfHU69zXaprB0Q3lWZvqFq+D63ok83R7ryZ3T Ewdmx5moTW2mTOafKSmb6fBszp1pYOp4wwwZhP2Ub/7aESictDtMtBxFwOR/XfyVFKh7 6k2ir5einDZc970zjTlplUQnuNEbX+ZGV6hKF3ShncanSnr+vwHclCTSZWQH7LaOvUnq 3URWvtSzMZ0UvE6XSkSUVneg0dzbx0MLqk9sN4gwo1wZpuEW4BU8/ovtaLw764qu07AD 71NKvG2Fge8/3agcgQq5cfuheuPt8T3Lz9/43+tcLj+IYhJx7Ut4jJ9ExLdGdh20m8xy UqkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n3-v6si17548672pgc.56.2018.05.24.19.43.28; Thu, 24 May 2018 19:43:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031692AbeEXUgl (ORCPT + 99 others); Thu, 24 May 2018 16:36:41 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:57010 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S967272AbeEXUgk (ORCPT ); Thu, 24 May 2018 16:36:40 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A18FBBB408; Thu, 24 May 2018 20:36:39 +0000 (UTC) Received: from [10.36.116.77] (ovpn-116-77.ams2.redhat.com [10.36.116.77]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7470A2166BB2; Thu, 24 May 2018 20:36:35 +0000 (UTC) Subject: Re: [PATCH v1 09/10] mm/memory_hotplug: teach offline_pages() to not try forever To: Michal Hocko Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Greg Kroah-Hartman , Rashmica Gupta , Balbir Singh , Andrew Morton , Vlastimil Babka , Dan Williams , Joonsoo Kim , Pavel Tatashin , Reza Arbab , Thomas Gleixner References: <20180523151151.6730-1-david@redhat.com> <20180523151151.6730-10-david@redhat.com> <20180524143953.GK20441@dhcp22.suse.cz> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <18a119a8-1b2c-a2cc-7ba1-d0a3c244d381@redhat.com> Date: Thu, 24 May 2018 22:36:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180524143953.GK20441@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 24 May 2018 20:36:39 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 24 May 2018 20:36:39 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'david@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24.05.2018 16:39, Michal Hocko wrote: > [I didn't really go through other patch but this one caught my eyes just > because of the similar request proposed yesterday] > > On Wed 23-05-18 17:11:50, David Hildenbrand wrote: > [...] >> @@ -1686,6 +1686,10 @@ static int __ref __offline_pages(unsigned long start_pfn, >> pfn = scan_movable_pages(start_pfn, end_pfn); >> if (pfn) { /* We have movable pages */ >> ret = do_migrate_range(pfn, end_pfn); >> + if (ret && !retry_forever) { >> + ret = -EBUSY; >> + goto failed_removal; >> + } >> goto repeat; >> } >> > > Btw. this will not work in practice. Even a single temporary pin on a page > will fail way too easily. If you really need to control this then make > it a retry counter with default -1UL. Interestingly, this will work for the one specific use case that I am using this interface for right now. The reason is that I don't want to offline a specific chunk, I want to find some chunks to offline (in contrast to e.g. DIMMs where you rely try to offline a very specific one). If I get a failure on that chunk (e.g. temporary pin) I will retry the next chunk. At one point, I will eventually retry this chunk and then it succeeds. > > We really do need a better error reporting from do_migrate_range and > distinguish transient from permanent failures. In general we shouldn't > even get here for pages which are not migrateable... I totally agree, I also want to know if an error is permanent or transient - and I want the posibility to "fail fast" (e.g. -EAGAIN) instead of looping forever. -- Thanks, David / dhildenb