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,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 0B83DC433DB for ; Wed, 13 Jan 2021 19:50:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B07F323382 for ; Wed, 13 Jan 2021 19:50:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B07F323382 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=soleen.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E55D78D008F; Wed, 13 Jan 2021 14:50:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E06188D008E; Wed, 13 Jan 2021 14:50:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1CB08D008F; Wed, 13 Jan 2021 14:50:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id B83F88D008E for ; Wed, 13 Jan 2021 14:50:19 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 866BA1F1A for ; Wed, 13 Jan 2021 19:50:19 +0000 (UTC) X-FDA: 77701793358.24.limit54_550290127520 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id 5CAFB1A4B1 for ; Wed, 13 Jan 2021 19:50:19 +0000 (UTC) X-HE-Tag: limit54_550290127520 X-Filterd-Recvd-Size: 6334 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Wed, 13 Jan 2021 19:50:18 +0000 (UTC) Received: by mail-ed1-f44.google.com with SMTP id g1so2597073edu.4 for ; Wed, 13 Jan 2021 11:50:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hkaHio9VTNAaaJDmEyRQXcJxkwJ/XswHkEgfldp61ZI=; b=DBMGxCUOdCPD0SifYoweomw1Y4FfNHp7XMpRyORz8ICzEC8hnO9+W2gxv7dcufnUdd mXKHLNN2knZn79lKiaZvdkn9JBdhHK8YGSsYBTrNCdRjaCsWiITLit4uBUxaAIqmw96t c4/3iPlmfgXuPO2mCRmuE/KMs3pQiHRU4epXJfyPJFXb8GNt5ruvjRnr9oSrC8xPfqRI UolhQ3coOMcq1dKzP8kPDAIQSvn4JO9sDTe0s51fUJDPTeN4bWaG5+Ns0VRvHpzy8cgb qFWHBtZcUByskLYs9X9XNcVDq8kGxX0QZOkkwxzA7CqvKd86pO8h5wloNkkbz38TsRiz NEoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hkaHio9VTNAaaJDmEyRQXcJxkwJ/XswHkEgfldp61ZI=; b=ek/qq3ZtahydbWCQ+EXsBwdkIFif7AOkj9bJ5HOL0w/xvprcNWmt31/ACKsqE7ciih /e2gkBjY8RxnBYUfN/waAe4p7qv/B8QhjkEyydWqDXT2nI6q/27/swgc5ioSbDOWAqAy 8GZNMgw+Dyp20fsMsAIbaY1i69QrjB/OHs/iAAbLmxRAxGXZXTzomPlQbwvc9hMcPcUu J+VSbXh+NhUXR/sLhGAmAE1g2b9/5mrL2gfbSuFxBARqLM33tsK61SGNV/YJnCQsnGIj yzH+PGnfmN44s7vIRVT9xtebsgi4OxYIaCwonlmuTVlUn/E4l54G8RZ9Hi+B4KyZR7eB gG+Q== X-Gm-Message-State: AOAM531r3DFfnz3VaVcKDuoMrtMAucnLAfjM4SUq8yRKwvlMYJfkonXv XSGOXhRhSZWQggZkIG/tWfurnQ+3a0ZGVun8DrazWQ== X-Google-Smtp-Source: ABdhPJxUwem33eQzEqaNtDEZLAOHpRjU0hOrw6ks7bEMUUESs7T5p/JZqZXOYsn7ezJOHVwn/vQhEdVylgMONGQxTP0= X-Received: by 2002:a50:b282:: with SMTP id p2mr3241176edd.210.1610567417733; Wed, 13 Jan 2021 11:50:17 -0800 (PST) MIME-Version: 1.0 References: <20201217185243.3288048-1-pasha.tatashin@soleen.com> <20201217185243.3288048-9-pasha.tatashin@soleen.com> <20201218104655.GW32193@dhcp22.suse.cz> <20201218131449.GZ32193@dhcp22.suse.cz> In-Reply-To: <20201218131449.GZ32193@dhcp22.suse.cz> From: Pavel Tatashin Date: Wed, 13 Jan 2021 14:49:41 -0500 Message-ID: Subject: Re: [PATCH v4 08/10] mm/gup: limit number of gup migration failures, honor failures To: Michal Hocko Cc: LKML , linux-mm , Andrew Morton , Vlastimil Babka , David Hildenbrand , Oscar Salvador , Dan Williams , Sasha Levin , Tyler Hicks , Joonsoo Kim , mike.kravetz@oracle.com, Steven Rostedt , Ingo Molnar , Jason Gunthorpe , Peter Zijlstra , Mel Gorman , Matthew Wilcox , David Rientjes , John Hubbard , Linux Doc Mailing List , Ira Weiny , linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" 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 Fri, Dec 18, 2020 at 8:14 AM Michal Hocko wrote: > > On Fri 18-12-20 07:43:15, Pavel Tatashin wrote: > > On Fri, Dec 18, 2020 at 5:46 AM Michal Hocko wrote: > > > > > > On Thu 17-12-20 13:52:41, Pavel Tatashin wrote: > > > [...] > > > > +#define PINNABLE_MIGRATE_MAX 10 > > > > +#define PINNABLE_ISOLATE_MAX 100 > > > > > > Why would we need to limit the isolation retries. Those should always be > > > temporary failure unless I am missing something. > > > > Actually, during development, I was retrying isolate errors > > infinitely, but during testing found a hung where when FOLL_TOUCH > > without FOLL_WRITE is passed (fault in kernel without write flag), the > > zero page is faulted. The isolation of the zero page was failing every > > time, therefore the process was hanging. > > Why would you migrate zero page in the first place? Simply instantiate > it. This is exactly the idea behind FOLL_WRITE; it causes zero pages to be created in the right zone right away, and no migration is necessary. > > > Since then, I fixed this problem by adding FOLL_WRITE unconditionally > > to FOLL_LONGTERM, but I was worried about other possible bugs that > > would cause hangs, so decided to limit isolation errors. If you think > > it its not necessary, I can unlimit isolate retires. > > It should have a really good reason to exist. Worries about some corner > cases is definitely not a reason to put some awkward retry mechanism. > My historical experience is that these things are extremely hard to get > rid of later. > > > > I am not sure about the > > > PINNABLE_MIGRATE_MAX either. Why do we want to limit that? migrate_pages > > > already implements its retry logic why do you want to count retries on > > > top of that? I do agree that the existing logic is suboptimal because > > > > True, but again, just recently, I worked on a race bug where pages can > > end up in per-cpu list after lru_add_drain_all() but before isolation, > > so I think retry is necessary. > > There are ways to make sure pages are not ending on pcp list. Have a > look at how hotplug does that. Sounds good to me, I will remove PINNABLE_MIGRATE_MAX, and leave only PINNABLE_ISOLATE_MAX for transient isolation errors. > > > > the migration failure might be ephemeral or permanent but that should be > > > IMHO addressed at migrate_pages (resp. unmap_and_move) and simply report > > > failures that are permanent - e.g. any potential pre-existing long term > > > pin - if that is possible at all. If not what would cause permanent > > > migration failure? OOM? > > > > Yes, OOM is the main cause for migration failures. > > Then you can treat ENOMEM as a permanent failure. Sounds good.