On Tue, Sep 20, 2016 at 03:59:45PM +1000, Dave Chinner wrote:
> On Mon, Sep 19, 2016 at 09:16:52PM -0700, Darrick J. Wong wrote:
> > On Tue, Sep 13, 2016 at 06:28:42PM +1000, Dave Chinner wrote:
> > > - __uint32_t xs_rmap_2_decrement;
> > > - __uint32_t xs_rmap_2_lshift;
> > > - __uint32_t xs_rmap_2_rshift;
> > > - __uint32_t xs_rmap_2_split;
> > > - __uint32_t xs_rmap_2_join;
> > > - __uint32_t xs_rmap_2_alloc;
> > > - __uint32_t xs_rmap_2_free;
> > > - __uint32_t xs_rmap_2_moves;
> > > +#define XFSSTAT_END_ABTB_V2 (XFSSTAT_END_BUF+__XBTS_MAX)
> > > + __uint32_t xs_abtb_2[__XBTS_MAX];
> > > +#define XFSSTAT_END_ABTC_V2 (XFSSTAT_END_ABTB_V2+__XBTS_MAX)
> > > + __uint32_t xs_abtc_2[__XBTS_MAX];
> > > +#define XFSSTAT_END_BMBT_V2 (XFSSTAT_END_ABTC_V2+__XBTS_MAX)
> > > + __uint32_t xs_bmbt_2[__XBTS_MAX];
> > > +#define XFSSTAT_END_IBT_V2 (XFSSTAT_END_BMBT_V2+__XBTS_MAX)
> > > + __uint32_t xs_ibt_2[__XBTS_MAX];
> > > +#define XFSSTAT_END_FIBT_V2 (XFSSTAT_END_IBT_V2+__XBTS_MAX)
> > > + __uint32_t xs_fibt_2[__XBTS_MAX];
> > > +#define XFSSTAT_END_RMAP_V2 (XFSSTAT_END_FIBT_V2+__XBTS_MAX)
> > > + __uint32_t xs_rmap_2[__XBTS_MAX];
> >
> > Are you planning to merge this before or after the refcount btree?
>
> Doesn't matter - either way I'll fix up one of them on merge into
> the for-next tree...
>
> >
> > > #define XFSSTAT_END_XQMSTAT (XFSSTAT_END_RMAP_V2+6)
> > > __uint32_t xs_qm_dqreclaims;
> > > __uint32_t xs_qm_dqreclaim_misses;
> > > @@ -229,26 +165,58 @@ struct xfsstats {
> > > __uint64_t xs_read_bytes;
> > > };
> > >
> > > +struct xfsstats {
> > > + union {
> > > + struct __xfsstats s;
> > > + uint32_t a[XFSSTAT_END_XQMSTAT];
> > > + };
> >
> > /me wonders if there ought to be a build time check to make sure that
> > these two are really the same size? They look all right as is, but
> > I can see myself forgetting to change something and screwing it up. :(
>
> It isn't the same size, because struct __xfsstats has three u64
> stats at the end that aren't part of the u32 array indexed by
> XFSSTAT_END_XQMSTAT. If we get the calculation of
> XFSSTAT_END_XQMSTAT wrong , then the output of the stats in the proc
> and sysfs files is screwed up because it treats the stats as an
> array of u32 items of that same size. So it's fairly obvious when
> it gets broken...
Well ok, how about a build time check that the sizes are off by exactly how
much we expect them to be? I guess I'd eventually notice the /proc output
looking weird after staring at bad numbers for long enough... ;)
<shrug> Your call though. :)
--D
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
