On Thu, Feb 13, 2025 at 06:22:21AM +0100, Christoph Hellwig wrote:
> On Fri, Feb 07, 2025 at 10:33:50AM -0800, Darrick J. Wong wrote:
> > > + spin_lock_init(&zi->zi_used_buckets_lock);
> > > + for (i = 0; i < XFS_ZONE_USED_BUCKETS; i++) {
> > > + zi->zi_used_bucket_bitmap[i] =
> > > + bitmap_zalloc(mp->m_sb.sb_rgcount, GFP_KERNEL);
> >
> > I wonder how long until this becomes a scalability problem, on my device
> > with 131k zones, this is a 16k contiguous allocation.
>
> This should probably be a kvmalloc allocation, I'll see if we want
> to open code it or add a new helper. 16k should be fine at mount
> time, but the devices aren't going get smaller in the next years.
Well I guess if it /is/ a problem we can always reuse the xbitmap32
code. :)
> > > + return false;
> > > +
> > > + xfs_info(mp, "reclaiming zone %d, used: %u/%u, bucket: %u",
> > > + rtg_rgno(victim_rtg), rtg_rmap(victim_rtg)->i_used_blocks,
> > > + rtg_blocks(victim_rtg), bucket);
> >
> > Tracepoint?
> >
> > > + trace_xfs_zone_reclaim(victim_rtg);
>
> Here :), but yes, the printk is probably too noisy for the default
> build even if it's really useful for debugging.
<nod>
--D
