RE: [f2fs-dev] [PATCH] f2fs: check all ones or zeros bitmap withinteger data type for better mount performance

[Chao Yu]

Hi Kim,

> -----Original Message-----
> From: Jaegeuk Kim [mailto:jaegeuk.kim@xxxxxxxxxxx]
> Sent: Wednesday, October 23, 2013 5:32 PM
> To: Chao Yu
> Cc: linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx; linux-fsdevel@xxxxxxxxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx; 'èå'
> Subject: RE: [f2fs-dev] [PATCH] f2fs: check all ones or zeros bitmap with integer
> data type for better mount performance
> 
> Hi,
> 
> 2013-10-23 (ì), 11:23 +0800, Chao Yu:
> > Hi, Kim:
> >
> > > -----Original Message-----
> > > From: Jaegeuk Kim [mailto:jaegeuk.kim@xxxxxxxxxxx]
> > > Sent: Tuesday, October 22, 2013 8:24 PM
> > > To: Chao Yu
> > > Cc: linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx;
> > > linux-fsdevel@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; èå
> > > Subject: Re: [f2fs-dev] [PATCH] f2fs: check all ones or zeros bitmap
> > > with integer data type for better mount performance
> > >
> > > Hi,
> > >
> > > 2013-10-22 (í), 17:28 +0800, Chao Yu:
> > > > Previously, check_block_count check valid_map with bit data type
> > > > in common scenario that sit has all ones or zeros bitmap, it makes
> > > > low mount performance.
> > > > So let's check the special bitmap with integer data type instead
> > > > of the bit one.
> > > >
> > > > Signed-off-by: Tan Shu <shu.tan@xxxxxxxxxxx>
> > > > Signed-off-by: Yu Chao <chao2.yu@xxxxxxxxxxx>
> > > > ---
> > > >  fs/f2fs/segment.h |   13 +++++++++++++
> > > >  1 file changed, 13 insertions(+)
> > > >
> > > > diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index
> > > > 7f94d78..d43ab9f 100644
> > > > --- a/fs/f2fs/segment.h
> > > > +++ b/fs/f2fs/segment.h
> > > > @@ -543,6 +543,7 @@ static inline void check_block_count(struct
> > > > f2fs_sb_info *sbi,  {
> > > >  	struct f2fs_sm_info *sm_info = SM_I(sbi);
> > > >  	unsigned int end_segno = sm_info->segment_count - 1;
> > > > +	int *valid_map = (int *)raw_sit->valid_map;
> > > >  	int valid_blocks = 0;
> > > >  	int i;
> > > >
> > > > @@ -552,6 +553,19 @@ static inline void check_block_count(struct
> > > > f2fs_sb_info *sbi,
> > > >  	/* check boundary of a given segment number */
> > > >  	BUG_ON(segno > end_segno);
> > > >
> > > > +	/* check all ones or zeros valid_map */
> > > > +	if (GET_SIT_VBLOCKS(raw_sit) == 0) {
> > > > +		for (i = 0; i < SIT_VBLOCK_MAP_SIZE / sizeof(int); i++)
> > >
> > > We cannot guarantee all the time that SIT_VBLOCK_MAP_SIZE is
> > > multiple of sizeof(int).
> > Well, It's really large changes for f2fs if SIT_VBLOCK_MAP_SIZE value is being
> modified.
> 
> But, it can be changed.
> Please do not add any unnecessary assumption.
Got it, sorry for the unmeaning assumption.

> 
> >
> > > How about using memcmp() with __u8?
> > Do you mean that we can alloc all zeros or ones memory in
> > SIT_VBLOCK_MAP_SIZE size, then memcmp() it with sit bitmap by __u8?
> 
> Yap.
> Ah, but there is another one.
> It would be better to use find_next_bit_le() and find_next_zero_bit_le().
> Any idea?
Good point.
I try to use memcmp(bitmap, bitmap+1, size-1) and bitmap[0], 
But yours got better performance and readable.
Thanks.

> 
> >
> > >
> > > > +			if (unlikely(valid_map[i] != 0))
> > > > +				BUG();
> > > > +		return;
> > > > +	} else if (GET_SIT_VBLOCKS(raw_sit) == sbi->blocks_per_seg) {
> > > > +		for (i = 0; i < SIT_VBLOCK_MAP_SIZE / sizeof(int); i++)
> > > > +			if (unlikely(valid_map[i] != -1))
> > > > +				BUG();
> > > > +		return;
> > > > +	}
> > > > +
> > > >  	/* check bitmap with valid block count */
> > > >  	for (i = 0; i < sbi->blocks_per_seg; i++)
> > > >  		if (f2fs_test_bit(i, raw_sit->valid_map))
> > > > ---
> > > >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe
> > > > linux-fsdevel" in the body of a message to
> > > > majordomo@xxxxxxxxxxxxxxx More majordomo info at
> > > > http://vger.kernel.org/majordomo-info.html
> > >
> > > --
> > > Jaegeuk Kim
> > > Samsung
> >
> 
> --
> Jaegeuk Kim
> Samsung

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/