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 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 B8470C6369E for ; Thu, 3 Dec 2020 00:20:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8C35D221EB for ; Thu, 3 Dec 2020 00:20:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C35D221EB 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 9B54F6B005C; Wed, 2 Dec 2020 19:20:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 964466B005D; Wed, 2 Dec 2020 19:20:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 853876B0068; Wed, 2 Dec 2020 19:20:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 707566B005C for ; Wed, 2 Dec 2020 19:20:23 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 32D35180AD811 for ; Thu, 3 Dec 2020 00:20:23 +0000 (UTC) X-FDA: 77550064326.12.step26_1c0abdb273b7 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 0C17118014500 for ; Thu, 3 Dec 2020 00:20:23 +0000 (UTC) X-HE-Tag: step26_1c0abdb273b7 X-Filterd-Recvd-Size: 5381 Received: from mail-ej1-f67.google.com (mail-ej1-f67.google.com [209.85.218.67]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Thu, 3 Dec 2020 00:20:22 +0000 (UTC) Received: by mail-ej1-f67.google.com with SMTP id d17so763904ejy.9 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=EE8fyyU4rfwLFd62Qj24dNLz7iV5poAq2z6LLX+CbWUn8wZ0gG4iEBCXyWZO1/tgLW OyLzx/sfwXa6xQPtXjBRbwULDZUT57kweNnB/6ew489Qi1v9BnTksEJWKcTWcf1b+aYq P9DU6wmIg15VVe6y+vQz94khvw9D802Xa5PsplUPtMvu11Z3N8SZFABwV5cVhDLFU9ye sPeGle1N5hSIj+iQx8bZmivnh+w+TTKnI5grDaMtCAjWXXeu2py5oTwqlJ/4iRSBRQeI UmyrM5MuXfcaJpbgJMduM9dcOJmeLAm9FizJF7lQ8n8m3kBsYYH0FM60JNLEgaaWD7nO kXrQ== X-Gm-Message-State: AOAM532B/AU85TkIaKwOXYmbbr1TrSbEfNCUtAMOqFaWSfGsDGiWwUTX 5V3VOt8hSv+vYbSlWSi+Qz/8yapc0dELWKti7L/49Q== X-Google-Smtp-Source: ABdhPJwwdl7YLLCIGODiaqCSmqirYVISBEcm2GnTZz/wtia75XuprrcOofv26LOz83Y1rcxAFG6YRXhTgH+cMYpSMWc= 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" 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: > 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