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 D45C0C001B0 for ; Tue, 15 Aug 2023 20:39:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB47694002D; Tue, 15 Aug 2023 16:39:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C64108D0001; Tue, 15 Aug 2023 16:39:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B2D5C94002D; Tue, 15 Aug 2023 16:39:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A4B1C8D0001 for ; Tue, 15 Aug 2023 16:39:30 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 40560160372 for ; Tue, 15 Aug 2023 20:39:30 +0000 (UTC) X-FDA: 81127504500.27.72233C8 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf23.hostedemail.com (Postfix) with ESMTP id 1CBF7140010 for ; Tue, 15 Aug 2023 20:39:26 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=B9NRggmS; spf=pass (imf23.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.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=1692131967; 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=ZM8Vus7SYRyjZ9hahA/SIHNX1amWb1Q96RY2XciYRCo=; b=MRJL5oMOyMbjCX2fdc7C7OqqCW/IHCPTom9HekJUwnmf6P0JtezUnMpuV0jBQ+8NJ0uvM7 86o0bLpO3hj+zd0DqTRoG63J8k6LP0nBF4K9z3zWQIc2cprnxMxLZcxP4QdwCfE2g5b0Kr HrLdgbjx9n5UhFssTo8DvWkZBCK8loI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692131967; a=rsa-sha256; cv=none; b=5e/4D8VPIHU5DeF606iFXxavhQtZCyw4cmT1dlp/3eeofH7hs92slJQvJtiTo5gL2Q9vPA bebr3fMLVZu+JLVlXP2g/0BxL9TprTT7bd/KH76soHrSLaK3dDlA8+bOZXrOi1Jxf0D9T1 PC8pC49ZznUM033zYEC8RErdQe1CgWI= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=B9NRggmS; spf=pass (imf23.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.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=1692131966; 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=ZM8Vus7SYRyjZ9hahA/SIHNX1amWb1Q96RY2XciYRCo=; b=B9NRggmSm2f7W9nk7W+rDC9/UqUrjYaKiC79BZ/boPFfGNS0goIPoMNPjS9BzfV/kufZZG ylasdpRy6QUT3XfkrhMCSgJBcOGsUAifloFdXh/G9cMzw7rCSX0imbp/Zet+/Q1VdjLBoX 9DH1gbZXzQmRmlDhRI760rX7RnGV2Fs= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-618-KbPkUyWCOzqfnG7w6cM5xw-1; Tue, 15 Aug 2023 16:39:24 -0400 X-MC-Unique: KbPkUyWCOzqfnG7w6cM5xw-1 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-40559875dd1so11067241cf.1 for ; Tue, 15 Aug 2023 13:39:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692131964; x=1692736764; 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=ZM8Vus7SYRyjZ9hahA/SIHNX1amWb1Q96RY2XciYRCo=; b=R07jMuyeR0jGtVOIXcPmNsf2yPAZXB1ZyGGoognc9JmBfc2Ak7AR1sNAFYG8ZKqdez uQwn5RTtI3MNmtvUqahtKTN2n6cLIUGhTjita4e06ni6m7qGu0jTkZNHeVvD+1tq15a6 MfbQLtar9HPiK+nB+mv4rzWVYLn8SQp+/3LrK3578UNm6IMhFOl2bPvjEkFhvLjlrL+w o+WFc3GayfslC1UrGpvMMWpnBqzUVf/LyIKfunQWSZC4vpimPrRrxNaJmD58E1N1bO43 GFzmbgslJG7iL+e6UTXYJUQ5COeqLlJ2x8CCh6gO0G7sLasvN7I1Q7853YWmBChNPBt9 zLGA== X-Gm-Message-State: AOJu0YwVbCw3mLVTwbApZ8orrKgF7fp1pwyEtnrNWbxyCyUINGmia+mF ouGgkAUvPZ0GxcMLQelpjPoLbREVVtgKB2hnmCSTL83vXQwpaLIfxXf2N3wXbX9z0VBycXNRzSY hUVC3DSyfC4g= X-Received: by 2002:a05:622a:1a8e:b0:40f:e384:b560 with SMTP id s14-20020a05622a1a8e00b0040fe384b560mr18711830qtc.1.1692131964067; Tue, 15 Aug 2023 13:39:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFtIAvbXXGEWNKvGaw16dmndy+4r/NC90p8M86FWmqv/yu68WwM5HI6X1kIy7z48YNh6BshRw== X-Received: by 2002:a05:622a:1a8e:b0:40f:e384:b560 with SMTP id s14-20020a05622a1a8e00b0040fe384b560mr18711822qtc.1.1692131963761; Tue, 15 Aug 2023 13:39:23 -0700 (PDT) Received: from x1n (cpe5c7695f3aee0-cm5c7695f3aede.cpe.net.cable.rogers.com. [99.254.144.39]) by smtp.gmail.com with ESMTPSA id m19-20020ac86893000000b00403cce833eesm4011916qtq.27.2023.08.15.13.39.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Aug 2023 13:39:23 -0700 (PDT) Date: Tue, 15 Aug 2023 16:39:16 -0400 From: Peter Xu To: Matthew Wilcox Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mike Kravetz , David Hildenbrand , Andrew Morton , Yu Zhao , Ryan Roberts , Yang Shi , Hugh Dickins , "Kirill A . Shutemov" Subject: Re: [PATCH RFC v2 0/3] mm: Properly document tail pages for a folio Message-ID: References: <20230814184411.330496-1-peterx@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-Rspamd-Queue-Id: 1CBF7140010 X-Rspam-User: X-Stat-Signature: 4srozfcxmogoybcrj94pjcgy8skbweof X-Rspamd-Server: rspam03 X-HE-Tag: 1692131966-996243 X-HE-Meta: U2FsdGVkX19OPJ44qBZSvPRzR8qaXEvvVymaZS9VeE4GZ05YFEl06Os6Coy5hSTHSWf49WC8siGLzLtl2MocHnQkwjpEhfGAJ62unigiSYX/BX3C5+Q0jdCnyxwzZ0Of0jZWa8SyNrDlb8sQV3v2vEV1a8ge0xRLZJokPknWa5MxBFE+s/V1tXZXKvNet9adGwFM3fbEI1dGsBQZe84bwBsY0mt+wz5V2luloMK42emkYjnaFlZd3siM75xWuOcYfb7WrfKRV9VeWspCq30JGixSgxgZvZX/34URE3+8rqon2lbP4qqIZm7Z5vclsnKgcfFBjVR9Bb98rVG5Oqw+OdCAVNY1JyY258jdJhuYUckx8/ci91aywDxE1EqIRdZ4NVqSbKT5AB3a3t7SwjlQAimU+guzvJFyloerk3t+rgX6kuvBd2UHiMMR9R7fz9AviLs+rMxR8qZY7cKGxyErr99ksyovZmA1TzF7ZPbqdyLR6rGAk4AdYl1U7Xz4aR5BFebFQcIkrZOF0eA0nW6WOH6UhJFq8idN9yZEBkhBWrrAf0QBFFjjIAN+x5q+lec1HYiXBAz+vfCdU/PAXblfx+OvRQUGrhosYSRDEobAPrhcPFSgwZ5J39ZQ0xOhiCqaTp0+P1+rgrid/mkk9ncAuh4HOZ84xMmoBoIkKrPz02OA6tUor7DGoubx1vrkOO1DLIdtdkHiI8E8yh5Qj83WwyjhY4ZPc5Etl1t+IFrRUmm0Dhw6GtN3A2AZjV50VRc+o0oTpKTOUHSNAP8lgAXUy1DIVIhFPPc39VUKJz5GAEoiJYUNNSEq4XuoYPZZAoadTbJt/nPjjA0wcvNlXv/DqrzjeDLq8/yd2QZWASGPjmMFnlCmGmtdK0xP+3JYIdIOLnWETbn6eu9SjleFm0VT+VvmY+ER85zADfvEz7XtTZKKJ2VcXUBoA3htvOOkoMH2uNumSSKAQtAT8h6q8uk 2Y5fXhA+ AANS/801Ez43U3CnFHFYf2M3MmtLSoVs2CEIZUsNlUbnsA9IKatJBNGwmfW1IhyE2+5ZzUyERKaH1gus8Zszo7ApsxW0Bdn7KSTFt1fhanj/LNMtF5IxckpmRFt5cq3lDPAzzGFNIQuCiG6Nnn8zAS0nXbk9FcBZ0D1BzFUjS4xKNWqNmc2Dk9WB4DPWff19wdwovEJASQvNL0/jeYbu0W7+Tgo3xrkPlBlYAcVSRyOh/spEgImkWu9+WuHxw90ofTjGbWLa+GPkWdJszxgbpBVdRzVg6G8LGSKbe8gmdKTjhK+JCVLMQoFrScl2sE2M18A258Ncz52cPUsSthAhEUsAsgVe22S0SaNPh7ghNtjChJbM= 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, Aug 15, 2023 at 09:16:47PM +0100, Matthew Wilcox wrote: > No, sometimes there are things which shouldn't be documented because they > don't matter, and when changing code sometimes we forget to change the > documentation, and then people read the documentation which is different > from the code, and they get confused. > > It matters that the various 'private' members line up. It matters > that folio->index matches page->index. It does not matter what > offset _entire_mapcount is at. That can be moved around freely and no > documentation needs to be changed. > > I don't want you to use FOLIO_MATCH to make any unnecessary assertions. > The only assertion missing is for _private_1 and _private_2a, and that's > why I wrote a patch to add them. I didn't mean to add assertions for _entire_mapcount (I don't even know how..), but _mapcount and _refcount to clamp the fields, then all fields can be clear, just like head/flags clamping the start of fields. One thing I can understand that you'd like to avoid these "offset" things is perhaps because you keep that in mind to, one day, have mmdesc replacing folio so folio doesn't need to match struct page at all some day, ideally. The order of fields, size of fields, etc. none of them should matter, when it comes, and we should go toward that. However my argument would be that, before that day comes IMHO we need some good documentation for us to know how the fields look like now, why they worked, and how to reuse new fields.. when that comes, we can just safely remove these documentations. It's just that these 'offset's still matter and matters a lot now, imho, but it's very confusing when read without some help. Let me try one more time to see how you think about it on an rfcv3. If that still doesn't get any form of ack from you, I'll put this aside. -- Peter Xu