linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Gu Zheng <guz.fnst@cn.fujitsu.com>
To: Changman Lee <cm224.lee@samsung.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	f2fs <linux-f2fs-devel@lists.sourceforge.net>,
	fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 3/4] f2fs: use find_next_bit_le rather than test_bit_le in, find_in_block
Date: Thu, 3 Jul 2014 09:05:21 +0800	[thread overview]
Message-ID: <53B4AC51.3040508@cn.fujitsu.com> (raw)
In-Reply-To: <20140702074903.GA7854@cm224.lee>

Hi Changman,
On 07/02/2014 03:49 PM, Changman Lee wrote:

> Hi, Gu
> 
> Unfortunately, find_next_bit isn't always better than test_bit.
> Refer to commit 5d0c667121bfc8be76d1580f485bddbe73465d1a
> 
> I remember that
> Perviously, Jaegeuk had changed find_next_bit to test_bit because
> find_next_bit spent much cpu time in the case of there is lot of dentries like a postmark.

Ah~, there was such a discussion before. But I think whether we can get
benefit from this depends on the condition of the bit-map.
I'll follow Jaegeuk's suggestion to get more effective data about this,
maybe it it can dispel our qualm.

> Sorry, I should have reported this quickly.

It's not late.:)

Thanks,
Gu

> 
> On Tue, Jun 24, 2014 at 06:20:41PM +0800, Gu Zheng wrote:
>> Use find_next_bit_le rather than test_bit_le to improve search speed
>> lightly.
>>
>> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
>> ---
>>  fs/f2fs/dir.c |   43 +++++++++++++++++++++----------------------
>>  1 files changed, 21 insertions(+), 22 deletions(-)
>>
>> diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
>> index 3edd561..ba510fb 100644
>> --- a/fs/f2fs/dir.c
>> +++ b/fs/f2fs/dir.c
>> @@ -93,42 +93,41 @@ static struct f2fs_dir_entry *find_in_block(struct page *dentry_page,
>>  			const char *name, size_t namelen, int *max_slots,
>>  			f2fs_hash_t namehash, struct page **res_page)
>>  {
>> -	struct f2fs_dir_entry *de;
>> -	unsigned long bit_pos = 0;
>> +	unsigned long bit_pos = 0, bit_start = 0;
>>  	struct f2fs_dentry_block *dentry_blk = kmap(dentry_page);
>>  	const void *dentry_bits = &dentry_blk->dentry_bitmap;
>> -	int max_len = 0;
>>  
>> -	while (bit_pos < NR_DENTRY_IN_BLOCK) {
>> -		if (!test_bit_le(bit_pos, dentry_bits)) {
>> -			if (bit_pos == 0)
>> -				max_len = 1;
>> -			else if (!test_bit_le(bit_pos - 1, dentry_bits))
>> -				max_len++;
>> -			bit_pos++;
>> -			continue;
>> +	while (bit_start < NR_DENTRY_IN_BLOCK) {
>> +		struct f2fs_dir_entry *de;
>> +		int max_len = 0;
>> +
>> +		bit_pos = find_next_bit_le(dentry_bits,
>> +					NR_DENTRY_IN_BLOCK, bit_start);
>> +
>> +		max_len = bit_pos - bit_start;
>> +		if (max_len > *max_slots) {
>> +			*max_slots = max_len;
>> +			max_len = 0;
>>  		}
>> +
>> +		if (bit_pos >= NR_DENTRY_IN_BLOCK)
>> +			break;
>> +
>>  		de = &dentry_blk->dentry[bit_pos];
>>  		if (early_match_name(name, namelen, namehash, de)) {
>>  			if (!memcmp(dentry_blk->filename[bit_pos],
>>  							name, namelen)) {
>>  				*res_page = dentry_page;
>> -				goto found;
>> +				return de;
>>  			}
>>  		}
>> -		if (max_len > *max_slots) {
>> -			*max_slots = max_len;
>> -			max_len = 0;
>> -		}
>> -		bit_pos += GET_DENTRY_SLOTS(le16_to_cpu(de->name_len));
>> +
>> +		bit_start = bit_pos
>> +				+ GET_DENTRY_SLOTS(le16_to_cpu(de->name_len));
>>  	}
>>  
>> -	de = NULL;
>>  	kunmap(dentry_page);
>> -found:
>> -	if (max_len > *max_slots)
>> -		*max_slots = max_len;
>> -	return de;
>> +	return NULL;
>>  }
>>  
>>  static struct f2fs_dir_entry *find_in_level(struct inode *dir,
>> -- 
>> 1.7.7
> 



  reply	other threads:[~2014-07-03  1:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-24 10:20 [PATCH 3/4] f2fs: use find_next_bit_le rather than test_bit_le in, find_in_block Gu Zheng
2014-06-25  2:30 ` [f2fs-dev] " Chao Yu
2014-06-25  2:53   ` Gu Zheng
2014-06-27  9:58 ` [PATCH V2 3/4] f2fs: use find_next_bit_le rather than test_bit_le in find_in_block Gu Zheng
2014-07-02  7:49 ` [PATCH 3/4] f2fs: use find_next_bit_le rather than test_bit_le in, find_in_block Changman Lee
2014-07-03  1:05   ` Gu Zheng [this message]
2014-07-02 10:30 ` Jaegeuk Kim
2014-07-03  1:13   ` Gu Zheng
2014-07-03 10:14   ` Gu Zheng
2014-07-04  5:36     ` Jaegeuk Kim
2014-07-04  6:21       ` Chao Yu
2014-07-04  8:04         ` Gu Zheng
2014-07-05  6:25           ` Jaegeuk Kim
2014-07-05 11:15             ` Chao Yu
2014-07-07  1:45             ` Changman Lee
2014-07-07  2:13               ` Gu Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53B4AC51.3040508@cn.fujitsu.com \
    --to=guz.fnst@cn.fujitsu.com \
    --cc=cm224.lee@samsung.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).