Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp104551pxu; Wed, 2 Dec 2020 16:24:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJwcB0kV2kv4WCq9rXB4t5pW+46HXknBoo+yB/2RAPFli+4SzV9ayXXVj+pwOHcEmgJMkkw/ X-Received: by 2002:a17:906:b0d8:: with SMTP id bk24mr301253ejb.113.1606955096325; Wed, 02 Dec 2020 16:24:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606955096; cv=none; d=google.com; s=arc-20160816; b=geLJa0S4KrCKea5AHETfLSbRBdvBsxmu5snv15RnWGVxUO4C3tW8NweVoeoIxtnTNC ZCnJEAtFFAcrhbsUjEyTwQn+7j+VkTmbqb2gF+Sb/mpqrKH8L/VOTNi6L8VI7O6fryHr OiDYbBhkODvVbeyNEaadFIXWHwtHF6kjhfI91cZBehN/0hsVymSjwNg9wEJbobzW4mTN i9ePCIp3NS5n3Dybp7p/ez9tEqCnL4bYjhcGOWnoP5NLV4zXjuu0Lihp50gfMUuCC9+g ZIEO+PraNmyEk7GRZbT1xztphkF1mZ0z7l/hb5wNaavi/uJ1lZfwHtSD7Dlz47CrU4qs hx7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=uiPBgP7DdxfOqaNnqn2QjWLvUmd4cmKVYw9/18ZZkzw=; b=W7a5dp+joOFkUYUYAjzztMdd2nnmN1mvrxMVM7YSiZmyytNRU1TNLX9cwD1YHHSnBY Z5A3ONPO+DHPTRN5KxKUKn/w+pGkckBp4BuJVc54mL740NDcC00W35fiJsbP+ARhu5Fk b94YMEk5aoYMo5KrhlguyRD8Fn4NWe+U3vYfCweMJ/pSzTxYaNsS0kTNa6h+J3hL+W6P zTL9iyRAzV8K4zvMXQJ3VrLDg1h/uxzGC0vOOl2vS/wbs+6qzHGqHVNDeUDzHl4JCeGJ +mDSIr+tBEG6BrxoEfF+WWcJTSnRqK5CDa6CkLth5z/tsV65Ms9KOXdbx++e/smJ9TdX P8qw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@soleen.com header.s=google header.b=RrGgKoNj; 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 md16si135119ejb.563.2020.12.02.16.24.33; Wed, 02 Dec 2020 16:24:56 -0800 (PST) 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; dkim=pass header.i=@soleen.com header.s=google header.b=RrGgKoNj; 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 S1728947AbgLCAVD (ORCPT + 99 others); Wed, 2 Dec 2020 19:21:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726299AbgLCAVC (ORCPT ); Wed, 2 Dec 2020 19:21:02 -0500 Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73B5AC0613D6 for ; Wed, 2 Dec 2020 16:20:22 -0800 (PST) Received: by mail-ej1-x643.google.com with SMTP id a16so797791ejj.5 for ; Wed, 02 Dec 2020 16:20:22 -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=uiPBgP7DdxfOqaNnqn2QjWLvUmd4cmKVYw9/18ZZkzw=; b=RrGgKoNjA9sakFld2DgYNQqlCq10c1anK/oZaeSFZHCQgdqJE1+v+6z5TtBiV1vOg+ chucFbEnWN2goQbdcJOcyT1XgDUkl8QvgswTkUXm4s3SNj4fKllQK9B7YURcoAPWPrkQ GvqIHePJhao+vF3Ad9hDhi796vaAkbno+9ONPOiLvNuPFBe9+P1vs8M502bVQKtsgDXY QyyHCqFMC1frtLa9YwqJGYIQHIz961+vVZjDxgFXg4521jnUyxCLFWsM38FyeH4QN/PZ j00AXtG0qtty25F2EaIHJvuOrnHLipnKd/Zx+loxQpS+sZrNFOi357o7aURkzodhvHTn 4hSg== 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=uiPBgP7DdxfOqaNnqn2QjWLvUmd4cmKVYw9/18ZZkzw=; b=ONZ/P1x0JvMN+WPvme+0P8bW3wUtKl4pMKKjVNCTZ+bh/L6GI13GgECh2w0E2ajbd6 XOtsy2mBWKHTR8izhMgzjFwdiDEciPEhUtjXKDXinx/5hkFfHC4VCQd3BYJrTkwOkk5x kgUJTmMxWxcJdfnNujeNhM69ymj/EsdpERqUZo/bMGEWfjmUn8jGcxAxaUOQq/tANYrJ u+j2H7u7peYYHdHUESXcxtNIbjJ5qQ50chEmFKcJkoOvvpl5yGD2ha4qbqDKeP7Qm4CV ERB1j6gF8FaCgPpjlxt63A59kFIt6QpF3jdN8NF8XkcTucCOsmle7R5MWSsVKBsW9RKG Rxug== X-Gm-Message-State: AOAM530WCVDC4AMeGQcbSwr1zYBJTHMe3qxJbGuxgsTnuv/lgS8qlOSo uQQHnuXAJ4N9ak+fUYGUUWRvc17ESoO4lVBLBlzccg== X-Received: by 2002:a17:906:d41:: with SMTP id r1mr272114ejh.383.1606954821170; Wed, 02 Dec 2020 16:20:21 -0800 (PST) MIME-Version: 1.0 References: <20201202052330.474592-1-pasha.tatashin@soleen.com> <20201202052330.474592-7-pasha.tatashin@soleen.com> <20201202163507.GL5487@ziepe.ca> In-Reply-To: <20201202163507.GL5487@ziepe.ca> From: Pavel Tatashin Date: Wed, 2 Dec 2020 19:19:45 -0500 Message-ID: Subject: Re: [PATCH 6/6] mm/gup: migrate pinned pages out of movable zone To: Jason Gunthorpe Cc: LKML , linux-mm , Andrew Morton , Vlastimil Babka , Michal Hocko , David Hildenbrand , Oscar Salvador , Dan Williams , Sasha Levin , Tyler Hicks , Joonsoo Kim , mike.kravetz@oracle.com, Steven Rostedt , Ingo Molnar , Peter Zijlstra , Mel Gorman , Matthew Wilcox , David Rientjes , John Hubbard Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > It is a good moment to say, I really dislike how this was implemented > in the first place. > > Scanning the output of gup just to do the is_migrate_movable() test is > kind of nonsense and slow. It would be better/faster to handle this > directly while gup is scanning the page tables and adding pages to the > list. Hi Jason, I assume you mean to migrate pages as soon as they are followed and skip those that are faulted, as we already know that faulted pages are allocated from nomovable zone. The place would be: __get_user_pages() while(more pages) get_gate_page() follow_hugetlb_page() follow_page_mask() if (!page) faultin_page() if (page && !faulted && (gup_flags & FOLL_LONGTERM) ) check_and_migrate this page I looked at that function, and I do not think the code will be cleaner there, as that function already has a complicated loop. The only drawback with the current approach that I see is that check_and_migrate_movable_pages() has to check once the faulted pages. This is while not optimal is not horrible. The FOLL_LONGTERM should not happen too frequently, so having one extra nr_pages loop should not hurt the performance. Also, I checked and most of the users of FOLL_LONGTERM pin only one page at a time. Which means the extra loop is only to check a single page. We could discuss improving this code farther. For example, I still think it would be a good idea to pass an appropriate gfp_mask via fault_flags from gup_flags instead of using PF_MEMALLOC_NOMOVABLE (previously PF_MEMALLOC_NOCMA) per context flag. However, those changes can come after this series. The current series fixes a bug where hot-remove is not working with making minimal amount of changes, so it is easy to backport it to stable kernels. Thank you, Pasha > > Now that this becoming more general, can you take a moment to see if a > better implementation could be possible? > > Also, something takes care of the gup fast path too? > > Jason