Re: [RFC PATCHv2 1/1] fs: ext4: Don't use CMA for buffer_head

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

 



On Wed, Sep 04, 2024 at 08:49:10AM +0800, Zhaoyang Huang wrote:
> >
> > After all, using GFP_MOVEABLE memory seems to mean that the buffer
> > cache might get thrashed a lot by having a lot of cached disk buffers
> > getting ejected from memory to try to make room for some contiguous
> > frame buffer memory, which means extra I/O overhead.  So what's the
> > upside of using GFP_MOVEABLE for the buffer cache?
>
> To my understanding, NO. using GFP_MOVEABLE memory doesn't introduce
> extra IO as they just be migrated to free pages instead of ejected
> directly when they are the target memory area. In terms of reclaiming,
> all migrate types of page blocks possess the same position.

Where is that being done?  I don't see any evidence of this kind of
migration in fs/buffer.c.

It's *possile* I suppose, but you'd have to remove the buffer_head so
it can't be found by getblk(), and then wait for bh->b_count to go to
zero, and then allocate a new page, and then copy buffer_head's page,
update the buffer_head, and then rechain the bh into the buffer cache.
And as I said, I can't see any kind of code like that.  It would be
much simpler to just try to eject the bh from the buffer cache.  And
that's consistent which what you've observed, which is that if the
buffer_head is prevented from being ejected because it's held by the
jbd2 layer until the buffer has been checkpointed.

> > Just curious, because in general I'm blessed by not having to use CMA
> > in the first place (not having I/O devices too primitive so they can't
> > do scatter-gather :-).  So I don't tend to use CMA, and obviously I'm
> > missing some of the design considerations behind CMA.  I thought in
> > general CMA tends to used in early boot to allocate things like frame
> > buffers, and after that CMA doesn't tend to get used at all?  That's
> > clearly not the case for you, apparently?
>
> Yes. CMA is designed for contiguous physical memory and has been used
> via cma_alloc during the whole lifetime especially on the system
> without SMMU, such as DRM driver. In terms of MIGRATE_MOVABLE page
> blocks, they also could have compaction path retry for many times
> which is common during high-order alloc_pages.

But then what's the point of using CMA-eligible memory for the buffer
cache, as opposed to just always using !__GFP_MOVEABLE for all buffer
cache allocations?  After all, that's what is being proposed for
ext4's ext4_getblk().  What's the downside of avoiding the use of
CMA-eligible memory for ext4's buffer cache?  Why not do this for
*all* buffers in the buffer cache?

					- Ted




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux