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.7 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 EE1A7C433C1 for ; Thu, 3 Dec 2020 14:17:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 40C6720784 for ; Thu, 3 Dec 2020 14:17:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 40C6720784 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3B6EF6B0036; Thu, 3 Dec 2020 09:17:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 365B56B005C; Thu, 3 Dec 2020 09:17:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 255946B0068; Thu, 3 Dec 2020 09:17:34 -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 0C1586B0036 for ; Thu, 3 Dec 2020 09:17:34 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C33658249980 for ; Thu, 3 Dec 2020 14:17:33 +0000 (UTC) X-FDA: 77552173986.08.road02_5a0440f273bc Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id A621C1819E772 for ; Thu, 3 Dec 2020 14:17:33 +0000 (UTC) X-HE-Tag: road02_5a0440f273bc X-Filterd-Recvd-Size: 5676 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Thu, 3 Dec 2020 14:17:31 +0000 (UTC) Received: by mail-qk1-f179.google.com with SMTP id b144so2094928qkc.13 for ; Thu, 03 Dec 2020 06:17:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=8OibpZHqlmZvNVYfBDxh1hs2pxMvlwSThz0lOwApQaI=; b=dk5q4Lr+q5IgxWjo0A+9TcXXXrq384wcGpfFnW+QthnBUzC+5B7hiePCXYDMPpV6jE sNhAIvlE1T5mx9PVfjK4oGcrSWpFcFeMzVu+qY+xubhZBvnXhJhAYP38b89l5ZZYibf9 ocSsdnRcueGyZCJvpT9QabpaDr/Oo55UVTpqQqm85hxK8UMQ3mqzE4IQkNLC9Wqo4cqT emcy7qR9d49DEeksCWwyjYGTuliI6iG0poQtlw8IIaDRn7kfinv8yVxM077suxO3eOa4 2KIKuaU0HTR6fp16fNrja+iOMPZgFPEyX6CGqQX4l857+vRgOlhbFMG5sIDG1rPhATEl L8Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=8OibpZHqlmZvNVYfBDxh1hs2pxMvlwSThz0lOwApQaI=; b=n9nujIE4NCymC9yZt+AJ4Y+orqS57KQthvYUpdXi9WiWbluxfpoZDPF4auQvzT/NiL l5pZy4HvFFE01CClAa9ThoN1E9kgjpjz56WcOMg2r1B7jFXoExmHUH/eWNcgxvhQg8SS jizXws1qnsSS2xubnlCyKdBDHX9K/k4Qf/t1rKeefFrNcPJXjfRxms315MV7l23i6L/A lDbpwRV88qdBiiAIVcl216BIVPWtPJS5so0wR1h7tRY1jSomZDWNCMXd/Vp9ecJS3Jhb 66qtbWJUwCPn+BobWynq4HtIvoGhE5wCLQ9cPALVDPibcyqqvRFX1KxeO0+o2b7/yZQP qa9A== X-Gm-Message-State: AOAM5306sy5Uqh335iMMarnfIimcTdyeKoZuWCtlpnznD16m8+VWG6jy nt8cq8XM3uYNcY6HzAuy3SteqA== X-Google-Smtp-Source: ABdhPJwekmPGYB/ERv8yHMpnOrpDO1avwVj040d2RPkHZ1T7FlCYSfz1dxpVnmg6r8sbfURRChh19A== X-Received: by 2002:a05:620a:1489:: with SMTP id w9mr3060597qkj.43.1607005051082; Thu, 03 Dec 2020 06:17:31 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id k188sm1386697qkd.98.2020.12.03.06.17.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Dec 2020 06:17:29 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kkpQH-005V9B-25; Thu, 03 Dec 2020 10:17:29 -0400 Date: Thu, 3 Dec 2020 10:17:29 -0400 From: Jason Gunthorpe To: Pavel Tatashin 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 Subject: Re: [PATCH 6/6] mm/gup: migrate pinned pages out of movable zone Message-ID: <20201203141729.GS5487@ziepe.ca> References: <20201202052330.474592-1-pasha.tatashin@soleen.com> <20201202052330.474592-7-pasha.tatashin@soleen.com> <20201202163507.GL5487@ziepe.ca> <20201203010809.GQ5487@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed, Dec 02, 2020 at 08:34:32PM -0500, Pavel Tatashin wrote: > > Either here or perhaps even lower down the call chain when the page is > > captured, similar to how GUP fast would detect it. (how is that done > > anyhow?) > > Ah, thank you for pointing this out. I think I need to address it here: > > https://soleen.com/source/xref/linux/mm/gup.c?r=96e1fac1#94 > > static __maybe_unused struct page *try_grab_compound_head() > if (unlikely(flags & FOLL_LONGTERM) && is_migrate_cma_page(page)) > return NULL; > > I need to change is_migrate_cma_page() to all migratable pages. Will > study, and send an update with this fix. Yes, missing the two flows is a common error :( Looking at this code some more.. How is it even correct? 1633 if (!isolate_lru_page(head)) { 1634 list_add_tail(&head->lru, &cma_page_list); Here we are only running under the read side of the mmap sem so multiple GUPs can be calling that sequence in parallel. I don't see any obvious exclusion that will prevent corruption of head->lru. The first GUP thread to do isolate_lru_page() will ClearPageLRU() and the second GUP thread will be a NOP for isolate_lru_page(). They will both race list_add_tail and other list ops. That is not OK. > What I meant is the users of the interface do it incrementally not in > large chunks. For example: > > vfio_pin_pages_remote > vaddr_get_pfn > ret = pin_user_pages_remote(mm, vaddr, 1, flags | > FOLL_LONGTERM, page, NULL, NULL); > 1 -> pin only one pages at a time I don't know why vfio does this, it is why it so ridiculously slow at least. Jason