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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68743EB64D7 for ; Tue, 20 Jun 2023 20:12:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E290D8D0002; Tue, 20 Jun 2023 16:12:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD8CF8D0001; Tue, 20 Jun 2023 16:12:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA15B8D0002; Tue, 20 Jun 2023 16:12:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B86E28D0001 for ; Tue, 20 Jun 2023 16:12:34 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7B9D7C057A for ; Tue, 20 Jun 2023 20:12:34 +0000 (UTC) X-FDA: 80924223828.18.25C7850 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 112BA120015 for ; Tue, 20 Jun 2023 20:12:31 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SOAEspyw; spf=pass (imf29.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687291952; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7oXwoZ8RwLqLe3dWcXzZAE1NkRHUk+3J42l+YGXGeVc=; b=Cw/DWQ8T2gzdM5Ayj2YGt7MNv2+Gk5gDSLGkIKPd9uklT/XfhWu0Fg/b0wAMmBBM8OxWdK jRk7Wjob9rspxLM2UiBh9bPruTFc9MaAn8fDbRDvTi4csjbdbwZyjBMQup4QWEWUYY81gT qs/vrhDngRcof5dYHaNdlXyeCMYsmlI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687291952; a=rsa-sha256; cv=none; b=OY45gCG+TJD4/NlgY/eSm4ePuyvr6EZixaNA1uSjN7qwoVZuonc1GXbVohcDQwpNutO5bA 8G8nH1u2rx/R3iqiIteZxZXloqCt7fi2g++qFl3ozTXG1o7yyqlsvhqWo5WVIuB0Hhre8F 7xEqZ/Nru5BJh1RmiQEV0sEvu1g1TRE= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SOAEspyw; spf=pass (imf29.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687291951; h=from:from:reply-to:subject:subject: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=7oXwoZ8RwLqLe3dWcXzZAE1NkRHUk+3J42l+YGXGeVc=; b=SOAEspywXNVLb7aWc0ycZvBpMl9xLo/RdPYHUT/Eynh6AXZsXmSg4buIpDkEArevGWb+nM +JtdsNt7kZug43USBMclZhUYH/tVkYWh78J5YkXgRTrQkRD5cWSw3YO+ocdD2AJTyEjND6 RUbXi/3UINrC9orHRxPgA9apCZccbow= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-619-z0xB3T2NMouKrTFc0wAbQw-1; Tue, 20 Jun 2023 16:12:29 -0400 X-MC-Unique: z0xB3T2NMouKrTFc0wAbQw-1 Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-62dd9986b76so10141996d6.1 for ; Tue, 20 Jun 2023 13:12:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687291947; x=1689883947; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7oXwoZ8RwLqLe3dWcXzZAE1NkRHUk+3J42l+YGXGeVc=; b=kpD+I1macjlxPpagzHzno3NIxTmDgC1xkpcCf6BW/fekKM6kU6wzvw+OP+Q4Ii5iSy yZzV42S5657euKGvGcW/OvHoIpQKmzMl/thkJitjyObKaz7Tqtb+LGpgffqNkvkCgjEa z+qBsVdXLpX9e9NhwOsk0mUxi5suvkGQcz23BBLPZeEwavnalHillvrGzrjZqwaeNGMX oSwOYg6DziY6VTsq/6PKZOiGRCXZhWHub46D2ixj9KuqIdMK/Vl8pqY56M3h2UwX7tds lXwvdesUUbjQc9f+3uzx2a+LILvW9mcnn9FkESmj239sMSFNuwsP/mU0kg4hocJbAdZB kTEg== X-Gm-Message-State: AC+VfDwnU1bxBVUk101k+v52Ik9BCzc1rOquPoSFGBrooO3ziDwwu/SZ 9E6lENRLeWOiPER4o4E7TULLXTyaiSP4qhEXPQQ2PUsqwtbilTeKB2akHHDt+pN0+72LOinuRMk qOgoZEEqjFac= X-Received: by 2002:a05:6214:27eb:b0:616:870c:96b8 with SMTP id jt11-20020a05621427eb00b00616870c96b8mr16109355qvb.3.1687291947716; Tue, 20 Jun 2023 13:12:27 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5o7Di3dlhvIk+HgV8vPtkZ3osdYPg3Dh1c9EB8/W71nPxIahr7Cd8J0A2q7op/6+K5KADG0w== X-Received: by 2002:a05:6214:27eb:b0:616:870c:96b8 with SMTP id jt11-20020a05621427eb00b00616870c96b8mr16109335qvb.3.1687291947382; Tue, 20 Jun 2023 13:12:27 -0700 (PDT) Received: from x1n (cpe5c7695f3aee0-cm5c7695f3aede.cpe.net.cable.rogers.com. [99.254.144.39]) by smtp.gmail.com with ESMTPSA id f22-20020a0caa96000000b0062deea179aesm1618650qvb.22.2023.06.20.13.12.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jun 2023 13:12:27 -0700 (PDT) Date: Tue, 20 Jun 2023 16:12:25 -0400 From: Peter Xu To: David Hildenbrand Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrea Arcangeli , Mike Rapoport , Matthew Wilcox , Vlastimil Babka , John Hubbard , "Kirill A . Shutemov" , James Houghton , Andrew Morton , Lorenzo Stoakes , Hugh Dickins , Mike Kravetz , Jason Gunthorpe Subject: Re: [PATCH v2 5/8] mm/gup: Accelerate thp gup even for "pages != NULL" Message-ID: References: <20230619231044.112894-1-peterx@redhat.com> <20230619231044.112894-6-peterx@redhat.com> <02a057a3-3d9e-4013-8762-25ceb1beec86@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Stat-Signature: h7zen1wickwh9e31a44y4teddaqwrocd X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 112BA120015 X-Rspam-User: X-HE-Tag: 1687291951-528240 X-HE-Meta: U2FsdGVkX1+7fRQj8Y0Ew6CyR5zuwyL4s9D5TAMfPt5r67bhVPBOOU2Rzs6rHhkcd0bMdPkTckDSL4OD0wW1XLUSsBnFtz+Up/s3V+pkOe3BwC9eetFrmnT47H2MxkIEkbcEOi8x7sVAteAnqY60UFxcXjxzPdaHC1qWa5NxEqCrJEU+gBXhk9U2FR2R2TTEum9uB2wkumAhoQi5tLpXuGfOl7Y+HjobynuDPkE82kZQf4RT6HzbhR/skfzqykxd7NI4RLBgaA1/0d4f0ALkr0Mar31CFQNiGhgk2cnhukHKCRi+9fBGRRaMzwImurlNUEmhlu9oCfZSc72UlIVBg8Ia5kqQLoTmkeBcXKnjEgJ7KxNozWHIbcLW0HBrucA5IhlF6URa2YyiSE4C6SJl4LJDlZ6cxTnoS6YzHVUQ81vLCQTmFF3fpIW3EWb2WkX6H1UIN60jhG3TyLjsBkoDukuvIiL18R8S3WcEHa7ASXei+t+sVKDp0lDNBDDvifFhgJ86cVOqYV18Plkw3SSBCrbZCcJ4ASdK5s3GowSyVpUyMcWj/S0EUZaLoSX97ccLbwSc75gQfMJNlHtlP/ROgKh6FVAbdp901vdtwFxE1xDCetg+Hd+H21qzHeeQRzV3uaVEjQKkk/g6Fikzb/VCatiJ1FeNU/5eLGfcmdWtWv3M2rr22me69W7NXYUdQA5jQirVuWEfIVHO6FcjHe2NmoKqWXq2wTH7IcCUWTuubAl/oSjsFPNs2kIp8Ktf7GnGJLgkNz0LhTJwFaGYKih05HJgpbsndjvKH2X0DqOs0WbIm0ZW1Jns+aj6jxfhdgtZOuKSlXzgLFyAJlkYGlMGf9G7N+vuU8zKVHz8WwJHdnnTWAF3Ko57SMqIJkNkGSCgkI+O+L9rYzHt80XSkCGAldoA/+OK78O9URsZpb0a++1XrCJwLrBDSZSe3YGVGCsIrbU7cS7ofKX2n6C2nrx bICov2qj xVIzWbmkmzmCeJF+RMNc2wenlvWoMCnZvNWmRgRz1NXK0EcfHlg90bRe93zN4tm8gtyYdaUhErNy3TfvAVCcTTQxzmsgon6lNGUmbQCpHjAGelZg++HssSBLHBiBXBP1jjKRlF+qBQVdbDsDjLurxR3dpGzPYeTBnMmx7LSFy70rpe/sjQ9QU7NoYJL7pyhCzOfY60/DfFM9VkvIZWAi0C1u6Shgd85Oxv+9jKKGEB1NET8ZDoxOWdiMWrvSofX19in93YfWxZqa+3D4ncgM7OTgAu+WeznQC9czxg6OZpPc3zA/MuSjEJo5kSvYpf5S0GSEgRF+hMnDafqA7mlwTU5vY3Qous7949p21kildXNmcyrW1ocPHAaVF3Me6RQ0y0dgt5B/zQ1yEEFJiqeoRXFWQEQ== 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 Tue, Jun 20, 2023 at 08:02:41PM +0200, David Hildenbrand wrote: > Thinking about why we have the flush_anon_page/flush_dcache_page stuff here > and not in GUP-fast ... I suspect that all GUP-fast archs don't need that > stuff. Yeah that's a bit confusing, and I sincerely don't know the answer. Though here I had the other side of the feeling - I feel like gup-fast should also do it.. but maybe it's just get missed. AFAIU the idea was that the data can be mis-aligned between user / kernel, and if it's needed on slow gup I don't see why it's not needed in fast.. There're still a few archs that implemented flush_dcache_page() but meanwhile has HAVE_FAST_GUP selected, like arm/arm64/powerpc. It's just getting out of scope of what this series wanted to achieve. > I was wondering if there are some possible races with the flush_anon_page() > / flush_dcache_page() on a page that might have been unmapped in the > meantime (as we dropped the PT lock ...). > > Some flush_dcache_page() implementations do some IMHO confusing > page_mapcount() things (like in arch/arc/mm/cache.c). But maybe the unmap > code handles that as well ... and most likely these archs don't support THP. Maybe true. It seems that the page_mapcount() was mostly used to identify whether a page is mapped in the userspace address space, if so I'd worry less because the only race possible here, iiuc, is when the user unmaps the page concurrently (and since we got it from gup it must have been mapped once). Then I would assume the caller should be prepared for that, and the flush_dcache_page() won't matter too much in this case I assume, if the userspace dropped all the data anyway - the whole page* can already be invalid for that VA for a completed unmap. > > Anyhow, just a note that the flush_anon_page/flush_dcache_page left me > confused. I share the same confusion. Hopefully, what this series did here was not changing that, at least not making it worse. -- Peter Xu