Re: brd in a memdesc world

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxx                              +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





[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux