Re: [mm, net-next v2] mm: net: memcg accounting for TCP rx zerocopy
From: Michal Hocko <mhocko@suse.com>
Date: 2021-03-24 09:13:37
Also in:
cgroups, linux-mm, lkml
On Tue 23-03-21 11:47:54, Arjun Roy wrote:
On Tue, Mar 23, 2021 at 7:34 AM Michal Hocko [off-list ref] wrote:quoted
On Wed 17-03-21 18:12:55, Johannes Weiner wrote: [...]quoted
Here is an idea of how it could work: struct page already has struct { /* page_pool used by netstack */ /** * @dma_addr: might require a 64-bit value even on * 32-bit architectures. */ dma_addr_t dma_addr; }; and as you can see from its union neighbors, there is quite a bit more room to store private data necessary for the page pool. When a page's refcount hits zero and it's a networking page, we can feed it back to the page pool instead of the page allocator. From a first look, we should be able to use the PG_owner_priv_1 page flag for network pages (see how this flag is overloaded, we can add a PG_network alias). With this, we can identify the page in __put_page() and __release_page(). These functions are already aware of different types of pages and do their respective cleanup handling. We can similarly make network a first-class citizen and hand pages back to the network allocator from in there.For compound pages we have a concept of destructors. Maybe we can extend that for order-0 pages as well. The struct page is heavily packed and compound_dtor shares the storage without other metadata int pages; /* 16 4 */ unsigned char compound_dtor; /* 16 1 */ atomic_t hpage_pinned_refcount; /* 16 4 */ pgtable_t pmd_huge_pte; /* 16 8 */ void * zone_device_data; /* 16 8 */ But none of those should really require to be valid when a page is freed unless I am missing something. It would really require to check their users whether they can leave the state behind. But if we can establish a contract that compound_dtor can be always valid when a page is freed this would be really a nice and useful abstraction because you wouldn't have to care about the specific type of page. But maybe I am just overlooking the real complexity there. --For now probably the easiest way is to have network pages be first class with a specific flag as previously discussed and have concrete handling for it, rather than trying to establish the contract across page types.
If you are going to claim a page flag then it would be much better to have it more generic. Flags are really scarce and if all you care about is PageHasDestructor() and provide one via page->dtor then the similar mechanism can be reused by somebody else. Or does anything prevent that? -- Michal Hocko SUSE Labs