linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [LSF/MM/BPF Topic] Shared memory for shared file extents
@ 2022-02-09 21:54 Goldwyn Rodrigues
  2022-03-01 17:00 ` Matthew Wilcox
  0 siblings, 1 reply; 2+ messages in thread
From: Goldwyn Rodrigues @ 2022-02-09 21:54 UTC (permalink / raw)
  To: lsf-pc, linux-fsdevel; +Cc: dchinner, willy

Copy-on-write filesystem such as btrfs (or reflinks in XFS/OCFS2) have
files which share extents on disk. Multiple files can have extents
pointing to same physical disk location. When mutliple files share a
common extent and these files are read(), each file will have it's own
copy of the content in the page cache.

The problem is this leads to wastage of memory since multiple
copies of the same content is in memory. The proposal is to have a
common cache which would be used *for reads only* (excluding read before
writes for non page aligned writes).

I would like to discuss the problems which will arise to implement this:
 - strategies to maintain such a shared cache
   - location of the shared cache: device inode or separate inode?
   - all reads go through shared cache OR only shared extents 
     should be in shared cache
 - actions to perform if write occurs at offsets of shared extents
   - should it be CoW'd in memory? OR
   - move the pages from shared cache to inode's cache?
 - what should be done to the pages after writeback. Should they be
   dropped, so further reads are read into shared cache?
 - Shrinking in case of system memory pressure

An initial RFC patch was posted here:
https://lore.kernel.org/all/YXNoxZqKPkxZvr3E@casper.infradead.org/t/

-- 
Goldwyn

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [LSF/MM/BPF Topic] Shared memory for shared file extents
  2022-02-09 21:54 [LSF/MM/BPF Topic] Shared memory for shared file extents Goldwyn Rodrigues
@ 2022-03-01 17:00 ` Matthew Wilcox
  0 siblings, 0 replies; 2+ messages in thread
From: Matthew Wilcox @ 2022-03-01 17:00 UTC (permalink / raw)
  To: Goldwyn Rodrigues; +Cc: lsf-pc, linux-fsdevel, dchinner

On Wed, Feb 09, 2022 at 03:54:10PM -0600, Goldwyn Rodrigues wrote:
> Copy-on-write filesystem such as btrfs (or reflinks in XFS/OCFS2) have
> files which share extents on disk. Multiple files can have extents
> pointing to same physical disk location. When mutliple files share a
> common extent and these files are read(), each file will have it's own
> copy of the content in the page cache.
> 
> The problem is this leads to wastage of memory since multiple
> copies of the same content is in memory. The proposal is to have a
> common cache which would be used *for reads only* (excluding read before
> writes for non page aligned writes).
> 
> I would like to discuss the problems which will arise to implement this:
>  - strategies to maintain such a shared cache
>    - location of the shared cache: device inode or separate inode?
>    - all reads go through shared cache OR only shared extents 
>      should be in shared cache
>  - actions to perform if write occurs at offsets of shared extents
>    - should it be CoW'd in memory? OR
>    - move the pages from shared cache to inode's cache?
>  - what should be done to the pages after writeback. Should they be
>    dropped, so further reads are read into shared cache?
>  - Shrinking in case of system memory pressure
> 
> An initial RFC patch was posted here:
> https://lore.kernel.org/all/YXNoxZqKPkxZvr3E@casper.infradead.org/t/

Yes, we should discuss this.  Sorry I've been too busy to work on it
recently.  Hopefully I have time this year.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-03-01 17:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-09 21:54 [LSF/MM/BPF Topic] Shared memory for shared file extents Goldwyn Rodrigues
2022-03-01 17:00 ` Matthew Wilcox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).