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 412B6C2BBD4 for ; Fri, 18 Dec 2020 13:09:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E0D4023A79 for ; Fri, 18 Dec 2020 13:09:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727387AbgLRNJS (ORCPT ); Fri, 18 Dec 2020 08:09:18 -0500 Received: from mx2.suse.de ([195.135.220.15]:37320 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725885AbgLRNJR (ORCPT ); Fri, 18 Dec 2020 08:09:17 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1608296911; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Qy4X5XGLkjjTrEVnpyl9ubxnV3suDoRLMs36eWY7vx8=; b=l76U/9Q65OcRVxpjlhkrgzoI2O/GDE06QXEjmSrmOHTqE5Ih/2RQ1jIJG3bjvK1Y4ex2xq 8pw6RsXn2ZB7Oz9oWRONm2eAbpAwKQ3j3FevprsLmFtW13S9DlYK7cs6WEppEQvMHf0q36 xyYXBCkFyyT6u01tptEnHUwdGs/ZD60= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 819A5AEBE; Fri, 18 Dec 2020 13:08:30 +0000 (UTC) Date: Fri, 18 Dec 2020 14:08:25 +0100 From: Michal Hocko To: Pavel Tatashin 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 Subject: Re: [PATCH v4 05/10] mm/gup: migrate pinned pages out of movable zone Message-ID: <20201218130825.GY32193@dhcp22.suse.cz> References: <20201217185243.3288048-1-pasha.tatashin@soleen.com> <20201217185243.3288048-6-pasha.tatashin@soleen.com> <20201218094324.GT32193@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 18-12-20 07:24:53, Pavel Tatashin wrote: > On Fri, Dec 18, 2020 at 4:43 AM Michal Hocko wrote: > > > > On Thu 17-12-20 13:52:38, Pavel Tatashin wrote: > > > + * 1. Pinned pages: (long-term) pinning of movable pages is avoided > > > + * when pages are pinned and faulted, but it is still possible that > > > + * address space already has pages in ZONE_MOVABLE at the time when > > > + * pages are pinned (i.e. user has touches that memory before > > > + * pinning). In such case we try to migrate them to a different zone, > > > + * but if migration fails the pages can still end-up pinned in > > > + * ZONE_MOVABLE. In such case, memory offlining might retry a long > > > + * time and will only succeed once user application unpins pages. > > > > I still dislike this. Pinning can fail so there shouldn't be any reasons > > to break MOVABLE constrain for something that can be handled. If > > anything there should be a very good reasoning behind this decision > > documented. > > This is basically current behaviour, after patch 8, we can never pin > pages in the movable zone, so I will update this comment in that > patch. Then it would be much easier for review to state that the existing behavior is unchanged and do not update this comment just to remove it in a later patch. Because this patch should be straightforward change of the condition which pages to migrate (+some renaming which should be reasonably easy to follow). Maybe it would be even better to do the renaming separately without any functional changes and make only the change in the condition here. -- Michal Hocko SUSE Labs