Re: brd in a memdesc world

[Hannes Reinecke <hare@suse.de>]

On 3/13/24 19:28, Matthew Wilcox wrote:
> On Wed, Mar 13, 2024 at 06:15:26PM +0100, Pankaj Raghav wrote:
>> On 12/03/2024 18:40, Matthew Wilcox wrote:
>>> Hi Jens,
>>>
>>> I'm looking for an architecture-level decision on what the brd driver
>>> should look like once struct page has been shrunk to a minimal size
>>> (more detail at https://protect2.fireeye.com/v1/url?k=fdf5d9a0-9c7ecc9a-fdf452ef-74fe4860008a-d5306bf365c2b9b6&q=1&e=cbceae8b-61fb-4e3e-8f7c-6717d9b2431d&u=https%3A%2F%2Fkernelnewbies.org%2FMatthewWilcox%2FMemdescs )
>>>
>>> Currently brd uses page->index as a debugging check.  In the memdesc
>>> future, struct page has no members (you could store a small amount of
>>> information in it, but I'm not willing to commit to more than a few bits).
>>>
>>
>> Shouldn't we change brd to use folios? Once we do that, this will not
>> be a problem any more right?
> 
> We certainly could change brd to use folios.  But why would we want to?
> Hannes' work always allocates memory of a fixed size (a fixed multiple
> of PAGE_SIZE).  Folios are a medium-weight data structure (probably
> about 80 bytes once we get to memdescs).  They support a lot of things,
> eg belonging to an inode, having an index, being mappable to userspace,
> being lockable, accountable to memcgs, allowing extra private data,
> knowing their own size, ...
> 
> None of those things are needed for brd's uses.  All brd needs is to
> be able to allocate, kmap and free chunks of memory.  Unless there are
> plans to do more than this.
> 
The primary goal of my patchset is to make brd a test-bed for the LBS 
work; devices with a sector size larger than 4k are really hard to come
by. But really, it's just a testbed, and I'm not sure whether there's
a need for that in the general audience.
I can resubmit if you want ...

As for the memory overhead, I guess it only makes a noticable difference
when moving to hugepages, and have brd allocate hugepages only.
But that is future work for sure.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Ivo Totev, Andrew McDonald,
Werner Knoblich