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 75A45C43334 for ; Thu, 21 Jul 2022 19:53:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E7ADC6B0072; Thu, 21 Jul 2022 15:53:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E274F6B0073; Thu, 21 Jul 2022 15:53:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC8168E0001; Thu, 21 Jul 2022 15:53:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BCD426B0072 for ; Thu, 21 Jul 2022 15:53:15 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 9603B1A0AC0 for ; Thu, 21 Jul 2022 19:53:15 +0000 (UTC) X-FDA: 79712155950.30.6630475 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf19.hostedemail.com (Postfix) with ESMTP id 097E61A008E for ; Thu, 21 Jul 2022 19:53:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658433194; 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=1Ll575DJoxkh8lFqVhc8EJOSqoHRZjxOqFyBiQJk0Ho=; b=C3wY0zmhVFNdxRV3IXymVq5ePMohU/Zxko33f1TPeujDR/IUytQGkQRchLd9zX6344XuAb HAzk0hwH0AgfznS7nQaPFD+91Cz5Pfu1/d1aHOFC3FbkuHP2QBp9HIu9bDd1JGZnoYWCu1 SVGe5nmxZJqJ58WyRWKSc4n1+Q7udsU= 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.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-211-Gy7dS8boOXWls35VB8s38Q-1; Thu, 21 Jul 2022 15:53:13 -0400 X-MC-Unique: Gy7dS8boOXWls35VB8s38Q-1 Received: by mail-qv1-f69.google.com with SMTP id ld29-20020a056214419d00b004740c1dda13so1680337qvb.5 for ; Thu, 21 Jul 2022 12:53:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1Ll575DJoxkh8lFqVhc8EJOSqoHRZjxOqFyBiQJk0Ho=; b=SJJnfbPDEd/CGVBf8uhE/e1rQ+rOUw5Uztz6us4cqOqq7K6O0NOvp6KpSeMAUBxuT7 VJswaWQ92axVpbPXuH7jDEVvIPiQPLTMnS7nXgRegkbtD5rFI3ySsC3UxIB/GiNaBn/R 0+WWAiTYQtuq+CpuuQAZ5wDbElHGS5GLdCH0f90nIG3cDGKrPvXCkXFCiRy3U9SGZdE4 2tmlJiTV2tHSVWl9WbU9SCeRW6L2N4BQhpKuACO88BsA9WXg4ymwlpDx3TpoqgoPhRkm vaQZFnfP4l4PyE3icFZU8rpcdRuPEPIylBPFW01Ngt7wTzgOZtpCAoKqRqphn1fkMjiE R0aA== X-Gm-Message-State: AJIora8IWgItJiTQjTqha8FM9qcMaxs7qKFWCzacCKFFM1PNMBqs6KRH IEBUcvZUqBwPHtohzTbMj/UX0cqbfuC3inmeYaT8opWOd2vKuCH823j6pLx9pZUF5EyeM+FpfYi 9IR1582E8Jbs= X-Received: by 2002:a37:c401:0:b0:6b5:e0c5:39f4 with SMTP id d1-20020a37c401000000b006b5e0c539f4mr46587qki.455.1658433192863; Thu, 21 Jul 2022 12:53:12 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sqQdd9qUU3kIybPnGtmypi2hKHjCJQKLjdXOkzbmByKXn8wi2UcUFtmm3Y40UUfhsPdWP+ww== X-Received: by 2002:a37:c401:0:b0:6b5:e0c5:39f4 with SMTP id d1-20020a37c401000000b006b5e0c539f4mr46565qki.455.1658433192574; Thu, 21 Jul 2022 12:53:12 -0700 (PDT) Received: from xz-m1.local (bras-base-aurron9127w-grc-35-70-27-3-10.dsl.bell.ca. [70.27.3.10]) by smtp.gmail.com with ESMTPSA id k21-20020a05620a415500b006b5ed1eccc5sm2259278qko.44.2022.07.21.12.53.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Jul 2022 12:53:12 -0700 (PDT) Date: Thu, 21 Jul 2022 15:53:10 -0400 From: Peter Xu To: James Houghton 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 Subject: Re: [RFC PATCH 20/26] hugetlb: add support for high-granularity UFFDIO_CONTINUE Message-ID: References: <20220624173656.2033256-1-jthoughton@google.com> <20220624173656.2033256-21-jthoughton@google.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 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658433195; a=rsa-sha256; cv=none; b=Hx7NcDE8C0xTnpaAVLmFIzrDAaCMRFvNMOJpzMsbES+2i6//AGTZtFiNjrumOuhUxobeQz Hepac/iRrp6cDaQPwz6JaJjTQ/wedA5wlADCqR2nykKMnGc/OzJq0VnLt+lk5GlO6n54Hi 0rwQyqtXPs4e/S2XMCe8roQVtvEZr/E= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=C3wY0zmh; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf19.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658433195; 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=1Ll575DJoxkh8lFqVhc8EJOSqoHRZjxOqFyBiQJk0Ho=; b=5d29ZtgPu+RL1VwSrbFjjE17oWkqv1xJCP2vMhHGBlCyibrvY1qkanhpOx5pHTqgAlOpL8 Z8uolBdvwFBJNsgAmqN0Psy0gQxAnRXOFDmrN4XkxDZ8qEzStNEkUNwtApnsg1yiNjG/0/ AvPsV/SXItUp/VOFcT3hF1qe3LFbDEw= X-Rspamd-Queue-Id: 097E61A008E Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=C3wY0zmh; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf19.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=peterx@redhat.com X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: bdg1bxoms9418axw8fy5kwsu8wi98q85 X-HE-Tag: 1658433194-340012 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:44:58PM -0700, James Houghton wrote: > 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. Ah OK. :) > > 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. I just want to make sure this patch won't break existing uffd-minor users, or it'll be an kernel abi breakage. We'd still want to have e.g. existing compiled apps run like before, which iiuc means we should only use sub-page mapping when len!=hpagesize here. I'm not sure it's only about perf - the app may not even be prepared to receive yet another page faults within the same huge page range. -- Peter Xu