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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28F13C433EF for ; Tue, 12 Oct 2021 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 CCAF3608FE for ; Tue, 12 Oct 2021 14:17:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CCAF3608FE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 4BA396B0071; Tue, 12 Oct 2021 10:17:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 469B86B0072; Tue, 12 Oct 2021 10:17:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 30A3C6B0073; Tue, 12 Oct 2021 10:17:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0190.hostedemail.com [216.40.44.190]) by kanga.kvack.org (Postfix) with ESMTP id 2327C6B0071 for ; Tue, 12 Oct 2021 10:17:34 -0400 (EDT) Received: from smtpin37.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id CD72C1830EF3A for ; Tue, 12 Oct 2021 14:17:33 +0000 (UTC) X-FDA: 78687988386.37.C378A9E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf20.hostedemail.com (Postfix) with ESMTP id 70D23D0000B4 for ; Tue, 12 Oct 2021 14:17:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634048252; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=agsgYWYnZg+yAcmU9SygLt6cqNywm0a/D9nc5ylE2BQ=; b=Z1ToeRfxuWTWOE+UthLiK41nz7TXEMhP7CWs8to1EzaJ8kUiNypZP8Bn3gK3dZ4HO4eHtb VtuDQ+rr3FHMjWvuaGJrMNJbWjcgoybAohCkyV3zBcHj1iO8a0ASuctfH4vmx/SVAa8iO4 5EeUpz1uATEy0VcXr1s5Rr1PgVLGFS0= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-153-hF5j8PfUMfSxVUYHY1bxkg-1; Tue, 12 Oct 2021 10:17:31 -0400 X-MC-Unique: hF5j8PfUMfSxVUYHY1bxkg-1 Received: by mail-wr1-f69.google.com with SMTP id c2-20020adfa302000000b0015e4260febdso15812487wrb.20 for ; Tue, 12 Oct 2021 07:17:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=agsgYWYnZg+yAcmU9SygLt6cqNywm0a/D9nc5ylE2BQ=; b=modK2R7a6WJUYytqVbSc/CycY275y+vfSHHMOKeYhCTxhjsuWfwbyXkNgthszspWPd 8ZTvRvh67anPi6sSWX/SIKeMsqSbryJ6yQpL4t5VMIELqfod6XYmicnm+n4Vc3Ry/5E+ En7TXmUqGG1brwrHhXzbjjJxE3F1QApudPxsoQye2ntIrp6WhvS0ZTm3LjhN3xU3Zf9r GCM5dUDBHn06hOLdVzfSCjK/i6CG75pOBlBrt3GP4uYMtGevAAeqHxl2X3qP8XgYORdu zfDsHGkoHddYwoROh+XI/fU5QR976xF+eF9ygIocPB3YvtlW5Zt9JBfM1v8NAwQcPO2+ dUhQ== X-Gm-Message-State: AOAM532HvMcP4ESP5ktW/Y5v0Piod1d3+TnEUGHR2iEbqEd9Kh/GnIl1 S0rnG8mo7qxkOR21trufXhzr8sodNSa1RSCDb7y9MyOZhjwfxun36XBPxesfaHO3tQObwkf53YA Oqg5FubH858GyzwZF6hAJSDbeZCF+L10VyUFjGnnz1VJayd4Ga456AWuRXRc= X-Received: by 2002:a05:6000:15c6:: with SMTP id y6mr31869382wry.382.1634048250641; Tue, 12 Oct 2021 07:17:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwm9c50T9AhGAtiH7IW3D8ITGgSjSBU/HQr3nOKhZJY6UxmKFh/Rz+r0YzpZ2jpxYIFoYmfVA== X-Received: by 2002:a05:6000:15c6:: with SMTP id y6mr31869357wry.382.1634048250395; Tue, 12 Oct 2021 07:17:30 -0700 (PDT) Received: from [192.168.3.132] (p5b0c6a12.dip0.t-ipconnect.de. [91.12.106.18]) by smtp.gmail.com with ESMTPSA id z133sm2786731wmc.45.2021.10.12.07.17.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Oct 2021 07:17:29 -0700 (PDT) Subject: Re: [PATCH 03/62] mm: Split slab into its own type To: Matthew Wilcox Cc: linux-mm@kvack.org References: <20211004134650.4031813-1-willy@infradead.org> <20211004134650.4031813-4-willy@infradead.org> <02a055cd-19d6-6e1d-59bb-e9e5f9f1da5b@redhat.com> <425cd66f-2040-4278-6149-69a329a82f79@redhat.com> From: David Hildenbrand Organization: Red Hat Message-ID: <842357c1-bec2-654e-c782-569b1fd627b2@redhat.com> Date: Tue, 12 Oct 2021 16:17:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Z1ToeRfx; spf=none (imf20.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 70D23D0000B4 X-Stat-Signature: ukzzwfqgkriosrm3rypbjoxfdm8ut6fg X-HE-Tag: 1634048253-122945 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 12.10.21 16:13, Matthew Wilcox wrote: > On Tue, Oct 12, 2021 at 09:25:02AM +0200, David Hildenbrand wrote: >>>> What I can see is that we want (and must right now for generic >>>> infrastructure) keep some members of the the struct page" (e.g., flags, >>>> _refcount) at the very same place, because generic infrastructure relies on >>>> them. >>>> >>>> Maybe that has already been discussed somewhere deep down in folio mail >>>> threads, but I would have expected that we keep struct-page generic inside >>>> struct-page and only have inside "struct slab" what's special for "struct >>>> slab". >>>> >>>> I would have thought that we want something like this (but absolutely not >>>> this): >>>> >>>> struct page_header { >>>> unsigned long flags; >>>> } >>>> >>>> struct page_footer { >>>> atomic_t _refcount; >>>> #ifdef CONFIG_MEMCG >>>> unsigned long memcg_data; >>>> #endif >>>> } >>>> >>>> struct page { >>>> struct page_header header; >>>> uint8_t reserved[$DO_THE_MATH] >>>> struct page_footer footer; >>>> }; >>> >>> The problem with this definition is the number of places which refer >>> to page->flags and must now be churned to page->header.flags. >>> _refcount is rather better encapsulated, and I'm not entirely sure >>> how much we'd have to do for memcg_data. Maybe that was what you meant >>> by "this but absolutely not this"? I don't quite understand what that >>> was supposed to mean. >> >> Exactly what you mentioned above (changing all callers) is what I didn't >> want :) >> >> I was thinking of a way to have these "fixed fields" be defined only once, >> and ideally, perform any access to these fields via the "struct page" >> instead of via the "struct slab". >> >> Like, when wanting to set a page flag with a slab, access them >> >> ((struct page *)slab)->flags >> >> instead of using slab->flags. Essentially not duplicating these fields and >> accessing them via the "refined" page types, but only putting a "reserved" >> placeholder in. That would mean that we wouldn't need patch #1 and #2, >> because we wouldn't be passing around pgflags (using whatever fancy type we >> will decide on), all such accesses would continue going via the "struct >> page" -- because that's where these common fields actually reside in right >> now at places we cannot simply change -- because common infrastructure (PFN >> walkers, ...) heavily relyies on the flags, the refcount and even the >> mapcount (page types) being set accordingly. > > OK, I think I see what you want: > > struct slab { > struct page_header _1; > ... slab specific stuff ... > struct page_footer _2; > }; > > and then cast struct slab to struct page inside slab_nid(), > slab_address(), slab_pgdat(), slab_order() and so on. > > To a certain extent, I think that's just an implementation detail; the > important part is the use of struct slab, and then calling slab_nid() > instead of page_nid(). A wrinkle here is that slab does use some of > the bits in page->flags for its own purposes, eg PG_active becomes > PG_pfmemalloc for PageSlab pages. > > One of the things I did in the folio patches that I'm not too fond of > now is: > > struct folio { > union { > struct { > ... > }; > struct page page; > }; > }; > > so that I could do &folio->page instead of casting to struct page. > But maybe both of these approaches are just bad ideas, and I should do: > > static inline void slab_clear_pfmemalloc(struct slab *slab) > { > PageClearActive(slab_page(slab)); > } Yes, that's what I meant. -- Thanks, David / dhildenb