On Wed, Jun 25, 2025 at 08:21:57AM +0200, Christoph Hellwig wrote:
> On Tue, Jun 24, 2025 at 08:17:05PM +0200, Carlos Maiolino wrote:
> > > struct xlog {
> > > ...
> > > struct xlog_in_core *l_iclog;
> > > struct xlog_in_core *l_iclogs[XLOG_MAX_ICLOGS];
> > > };
> >
> > Thanks for the tip hch, but wouldn't this break the mount option? So far
> > the user can specify how many iclogs will be in memory, by allocating
> > a fixed array, we essentially lock it to 8 iclogs, no?
> >
> > Cheers, and thanks again for the review.
>
> Well, if you look at the helper I whiteboard coded below it only walks
> the array until the number of specified.
Sorry hch, my MUA miscolored your past message and I completely ignored it due
its color, won't happen again.
> As long as the maximum numbers
> of iclogs is relatively slow and/or the default is close to the maximum
> this seems optimal. If we every support a very huge number or default
> to something much lower than the default a separate allocation would
> be better here, but that's a trivial change.
Well, unless we decide in the future to increase the number of iclogs, this
seems doable, and the iclogs pointers array will fit into its own cache line,
eliminating the problem pointed by Dave.
I can do the work if we agree this can be useful somehow, at this point I'm
wondering if change this will actually improve anything :/
What you think? Is it actually worth redoing it this way, with a fixed array for
the iclogs pointers?
hch, Dave ^
Cheers.
>
>
