linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Chao Yu <chao2.yu@samsung.com>
To: "'Jaegeuk Kim'" <jaegeuk@kernel.org>,
	'이창만' <cm224.lee@samsung.com>,
	"'Gu Zheng'" <guz.fnst@cn.fujitsu.com>
Cc: '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: Fri, 04 Jul 2014 14:21:54 +0800	[thread overview]
Message-ID: <001301cf9750$5e897bc0$1b9c7340$@samsung.com> (raw)
In-Reply-To: <20140704053619.GA32528@jmac.local>

Hi Jaegeuk, Gu, Changman

> -----Original Message-----
> From: Jaegeuk Kim [mailto:jaegeuk@kernel.org]
> Sent: Friday, July 04, 2014 1:36 PM
> To: Gu Zheng
> Cc: f2fs; fsdevel; 이창만; 俞
> Subject: Re: [PATCH 3/4] f2fs: use find_next_bit_le rather than test_bit_le in, find_in_block
> 
> Well, how about testing with many ones in the bit streams?
> Thanks,
> 
> On Thu, Jul 03, 2014 at 06:14:02PM +0800, Gu Zheng wrote:
> > Hi Jaegeuk, Changman
> >
> > Just a simple test, not very sure it can address
> > our qualm.
> >
> > Bitmap size:216(the same as f2fs dentry_bits).
> > CPU: Intel i5 x86_64.
> >
> > Time counting based on tsc(the less the fast).
> > [Index of 1]	find_next_bit_le	test_bit_le
> > 0		20			117
> > 1		20			114
> > 2		20			113
> > 3		20			139
> > 4		22			121
> > 5		22			118
> > 6		22			115
> > 8		22			112
> > 9		22			106
> > 10		22			105
> > 11		22			100
> > 16		22			98
> > 48		22			97
> > 80		27			95
> > 104		27			92
> > 136		32			95
> > 160		32			92
> > 184		32			90
> > 200		27			87
> > 208		35			84
> >
> > According to the result, find_next_bit_le is always
> > better than test_bit_le, though there may be some
> > noise, but I think the result is clear.
> > Hope it can help us.:)
> > ps.The sample is attached too.
> >
> > Thanks,
> > Gu

I hope this could provide some help for this patch.

I modify Gu's code like this, and add few test case:

static void test_bit_search_speed(void)
{
	unsigned long flags;
	uint64_t tsc_s_b1, tsc_s_e1, tsc_s_b2, tsc_s_e2;
	int i, j, pos;
	const void *bit_addr;

	local_irq_save(flags);
	preempt_disable();
	
	printk("find_next_bit	test_bit_le\n");

	for (i = 0; i < 24; i++) {

		bit_addr = &bitmaps[i];

		tsc_s_b1 = rdtsc();

		for (j = 0, pos = 0; j < 1000; j++, pos = 0)
			while (pos < 216)
				pos = find_next_bit_le(bit_addr, 216, pos) + 1;

		mb();
		tsc_s_e1 = rdtsc();
		tsc_s_e1 -= tsc_s_b1;
		do_div(tsc_s_e1, 1000);

		tsc_s_b2 = rdtsc();

		for (j = 0, pos = 0; j < 1000; j++, pos = 0)
			while (pos < 216)
				test_bit_le(pos++, bit_addr);

		mb();
		tsc_s_e2 = rdtsc();
		tsc_s_e2 -= tsc_s_b2;
		do_div(tsc_s_e2, 1000);

		printk("%-16llu %-16llu\n", tsc_s_e1, tsc_s_e2);
	}

	preempt_enable();
	local_irq_restore(flags);
}
case: 11111111 11111111
		{255, 255, 255, 255, 255, 255, 255,
		 255, 255, 255, 255, 255, 255, 255,
		 255, 255, 255, 255, 255, 255, 255,
		 255, 255, 255, 255, 255, 255},
case: 10101010 10101010
		{170, 170, 170, 170, 170, 170, 170,
		 170, 170, 170, 170, 170, 170, 170,
		 170, 170, 170, 170, 170, 170, 170,
		 170, 170, 170, 170, 170, 170},
case: 11111111 00000000
		{255, 0, 255, 0, 255, 0, 255,
		 0, 255, 0, 255, 0, 255, 0,
		 255, 0, 255, 0, 255, 0, 255,
		 0, 255, 0, 255, 0, 255},
case: 00001111 00001111
		 {15, 15, 15, 15, 15, 15, 15,
		 15, 15, 15, 15, 15, 15, 15,
		 15, 15, 15, 15, 15, 15, 15,
		 15, 15, 15, 15, 15, 15}

and here are test result in my env. (Ubuntu vm, 768MB, i3-3220)
It seems find_next_bit works not so bad as I thought.

find_next_bit    test_bit_le
73               4209
62               1271
69               1585
50               2031
67               2255
82               2261
52               4007
79               2159
50               2043
55               2215
53               2393
72               3784
76               1879
61               2562
70               2702
62               2489
56               2307
54               2063
51               2258
69               2712
4133             3989  -- case: 11111111 11111111
2370             3024  -- case: 10101010 10101010
2608             2413  -- case: 11111111 00000000
2457             2506  -- case: 00001111 00001111

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-07-04  6:21 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
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 [this message]
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='001301cf9750$5e897bc0$1b9c7340$@samsung.com' \
    --to=chao2.yu@samsung.com \
    --cc=cm224.lee@samsung.com \
    --cc=guz.fnst@cn.fujitsu.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).