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 4BA95C43334 for ; Thu, 21 Jul 2022 19:45:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 489756B0072; Thu, 21 Jul 2022 15:45:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 41BD38E0001; Thu, 21 Jul 2022 15:45:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 28B8E6B0074; Thu, 21 Jul 2022 15:45:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1AE726B0072 for ; Thu, 21 Jul 2022 15:45:12 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D671B1A0AE0 for ; Thu, 21 Jul 2022 19:45:11 +0000 (UTC) X-FDA: 79712135622.16.DAFC4BD Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by imf06.hostedemail.com (Postfix) with ESMTP id 6954018006A for ; Thu, 21 Jul 2022 19:45:11 +0000 (UTC) Received: by mail-lj1-f178.google.com with SMTP id j26so3075468lji.1 for ; Thu, 21 Jul 2022 12:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wWzcp1Z8HWXlZGBmd2SY3dRRfAqxHf8nagIP1lsSW5w=; b=GfvL2JFNB8yDOfrBzXPR28ePl1mIvysTBOgaKcjnGva2ZTymhmVH+3mZDIioZs5lAz ERjUW3sMTOYwCNHAp73jtQ3XmGcQ7PWTNHkwwhll77e/9uFc3rhIc7vnZLzass58FLiR /okJG5sVVAthcVmBD9xoLnJLj/WpWqPKr6BiB1nwz6JG2skQR1BPkGKiSs0d8fO2EEYW TMbSh4Nrx7DZ95TYYIjXRcebiQCguVpTU/h1LY2hwiDNIUp4EF+lJXAGeQ2H+gYvwFhy b4WbAq2uLtd0DWU9bueYB7oj4pPk7msqqTh2/EjsE4U9CNUKEBMdqkM9Rulr4M+RoQwE gfNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wWzcp1Z8HWXlZGBmd2SY3dRRfAqxHf8nagIP1lsSW5w=; b=PvOOSuTBG11/WEsi24ZTHsyYAmqm9HeROFdzUoB2wY7+zw2/f9gpZHCGhqzPBJOB85 0c+fY35/1YvLsqZKQ4UESp8ptU2lOxPrBljxFNSmX1RLFpZqhwJ7RlhViEGrvZCMQiXT PQBIDtuWGd8+k90LP33g13FjgzsJ1dvCAryRu0ZnZi6NY0IOi/6ZH6Icp+Non7+RrT/9 m3vR2BnU3WW6aMyeeKrEqWtH6ZRB+p1Tz5bRW19clbGG/G/zOB2q5PA5cfZkOD3M2vTt i0XR6CUYjvv9iV+DLWedQTXtbbX4u9z1jJlWCtQturkgtRrse+uRWx/3Bsb6jxgEa2wm DA4w== X-Gm-Message-State: AJIora+oy21+FfHho7q7ceTXfZy46lTXKAb3N5sS+GVqCSr8z/M4JKz8 FA1QZlgqkcgxMurMMgXVo96XRrc4/OnWfiP2rPrRww== X-Google-Smtp-Source: AGRyM1u61sG92A3BoKVniDwQ4OfheO2BicDYZUFekdY25+Rm80SbqovMIgW9EWNRVmdUb7Zo5joN9hVOgLAkovEoeHE= X-Received: by 2002:a2e:b011:0:b0:25d:6208:77b1 with SMTP id y17-20020a2eb011000000b0025d620877b1mr19085765ljk.469.1658432709589; Thu, 21 Jul 2022 12:45:09 -0700 (PDT) MIME-Version: 1.0 References: <20220624173656.2033256-1-jthoughton@google.com> <20220624173656.2033256-21-jthoughton@google.com> In-Reply-To: From: James Houghton Date: Thu, 21 Jul 2022 12:44:58 -0700 Message-ID: Subject: Re: [RFC PATCH 20/26] hugetlb: add support for high-granularity UFFDIO_CONTINUE To: Peter Xu Cc: Mike Kravetz , Muchun Song , David Hildenbrand , David Rientjes , Axel Rasmussen , Mina Almasry , Jue Wang , Manish Mishra , "Dr . David Alan Gilbert" , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658432711; a=rsa-sha256; cv=none; b=bFtBJU9+abZbRfvAOi0lwrDOhLSnnZVm9ANna2B6Vm959CKgTLWk7MQagCym7sVCVD3/Y/ uxm05rW5v/6mMWFLnGWrdkMORMhaKqsgsiOHJdVQvaVUEJPHz8Fmt2TCajlogG+x9jYc83 i2r6jQzkDjK+nZ//gfdp/zO2/2t5LxA= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=GfvL2JFN; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of jthoughton@google.com designates 209.85.208.178 as permitted sender) smtp.mailfrom=jthoughton@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658432711; 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=wWzcp1Z8HWXlZGBmd2SY3dRRfAqxHf8nagIP1lsSW5w=; b=MeaWVP0/bBcvpggkt7eid36lncOkqp9SCYaC6qX/KgWVC3JIden5dN8+qJNR816kVNmF3j OLaAUb2S5IKTLRvIppUUBaH1wdQNI+eX3YHzDC9qQCRDT6YQ358HiCv1kyOwrNBXfVX8Gp 82gI0vN8Lm91GcCisA4i6alF/ad3CF0= Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=GfvL2JFN; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of jthoughton@google.com designates 209.85.208.178 as permitted sender) smtp.mailfrom=jthoughton@google.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 6954018006A X-Stat-Signature: uiai5ttzapyxzwjkudfrmp5c74iy1wjk X-HE-Tag: 1658432711-17408 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 Thu, Jul 21, 2022 at 12:09 PM Peter Xu wrote: > > On Wed, Jul 20, 2022 at 01:58:06PM -0700, James Houghton wrote: > > > > > > @@ -335,12 +337,16 @@ static __always_inline ssize_t __mcopy_atomic_hugetlb(struct mm_struct *dst_mm, > > > > > > copied = 0; > > > > > > page = NULL; > > > > > > vma_hpagesize = vma_kernel_pagesize(dst_vma); > > > > > > + if (use_hgm) > > > > > > + vma_altpagesize = PAGE_SIZE; > > > > > > > > > > Do we need to check the "len" to know whether we should use sub-page > > > > > mapping or original hpage size? E.g. any old UFFDIO_CONTINUE code will > > > > > still want the old behavior I think. > > > > > > > > I think that's a fair point; however, if we enable HGM and the address > > > > and len happen to be hstate-aligned > > > > > > The address can, but len (note! not "end" here) cannot? > > > > They both (dst_start and len) need to be hpage-aligned, otherwise we > > won't be able to install hstate-sized PTEs. Like if we're installing > > 4K at the beginning of a 1G hpage, we can't install a PUD, because we > > only want to install that 4K. > > I'm still confused... > > Shouldn't one of the major goals of sub-page mapping is to grant user the > capability to do UFFDIO_CONTINUE with len sub-page level)? If so, why len needs to be always hpagesize aligned? Sorry I misunderstood what you were asking. We allow both to be PAGE_SIZE-aligned. :) That is indeed the goal of HGM. If dst_start and len were both hpage-aligned, then we *could* set `use_hgm = false`, and everything would still work. That's what I thought you were asking about. I don't see any reason to do this though, as `use_hgm = true` will only grant additional functionality, and `use_hgm = false` would only -- at best -- be a minor performance optimization in this case. - James > > -- > Peter Xu >