ger.kernel.org'; 'li...@arm.linux.org.uk'; 'linux-arm-
> ker...@lists.infradead.org'
> Subject: Re: [RFC] change non-atomic bitops method
>
> On Mon, 9 Feb 2015 16:18:10 +0800 "Wang, Yalin"
> wrote:
>
> > > That we're running clea
On Mon, Feb 09 2015, "Wang, Yalin" wrote:
> I te-test the patch on 3.10 kernel.
> The result like this:
>
> VmallocChunk: 251498164 kB
> __set_bit_miss_count:11730 __set_bit_success_count:1036316
> __clear_bit_miss_count:209640 __clear_bit_success_count:4806556
> __test_and_set_bit_miss_count:0
On Mon, 9 Feb 2015 16:18:10 +0800 "Wang, Yalin"
wrote:
> > That we're running clear_bit against a cleared bit 10% of the time is a
> > bit alarming. I wonder where that's coming from.
> >
> > The enormous miss count in test_and_clear_bit() might indicate an
> > inefficiency somewhere.
> I te-t
ger.kernel.org'; 'li...@arm.linux.org.uk'; 'linux-arm-
> ker...@lists.infradead.org'
> Subject: Re: [RFC] change non-atomic bitops method
>
> On Tue, 3 Feb 2015 16:42:14 +0800 "Wang, Yalin"
> wrote:
>
> > I make a change in kernel to test hit/m
Hello,
[added some more context again]
On Tue, Feb 03, 2015 at 03:14:43PM +, David Howells wrote:
> > > - *p |= mask;
> > > + if ((*p & mask) == 0)
> > > + *p |= mask;
> > Care to fix the double space here while touching the code?
> >
> > I think the more natural check
Uwe Kleine-König wrote:
> Might be a matter of taste, but this check is equivalent to
>
> *p != (*p | mask)
>
> which is what you really want to test for.
I would argue that this is less clear as to what's going on.
David
--
To unsubscribe from this list: send the line "unsubscribe linu
On Tue, 3 Feb 2015 16:42:14 +0800 "Wang, Yalin"
wrote:
> I make a change in kernel to test hit/miss ratio:
Neat, thanks.
>
> ...
>
> After use the phone some time:
> root@D5303:/ # cat /proc/meminfo
> VmallocUsed: 10348 kB
> VmallocChunk: 75632 kB
> __set_bit_miss_count:10002 __set_
On Tue, Feb 03, 2015 at 03:17:30AM +0200, Kirill A. Shutemov wrote:
> Results for 10 runs on my laptop -- i5-3427U (IvyBridge 1.8 Ghz, 2.8Ghz Turbo
> with 3MB LLC):
I've screwed up the inner loop condition and step. As result the benchmark
touches the same cache line 8 times and scan SIZE/8 of mem
org'; 'linux-kernel@vger.kernel.org';
> 'li...@arm.linux.org.uk'; 'linux-arm-ker...@lists.infradead.org'
> Subject: Re: [RFC] change non-atomic bitops method
>
> On Tue, Feb 03 2015, Andrew Morton wrote:
>
> >
> > You aren't measuring the right
On Tue, Feb 03 2015, Andrew Morton wrote:
>
> You aren't measuring the right thing. You should compare
>
> if (p[i] != x)
> p[i] = x;
>
> versus
>
> p[i] = x;
>
> and you should do this for two cases:
>
> a) p[i] == x
>
> b) p[i] != x
>
>
> The first code sequence will
On Tue, 03 Feb 2015 00:40:31 -0800 (PST) David Miller
wrote:
> From: Andrew Morton
> Date: Mon, 2 Feb 2015 22:38:51 -0800
>
> > It is only with both these ratios that we can work out whether the
> > patch is a net gain. My suspicion is that set_bit on an already-set
> > bit is so rare that th
; 'li...@arm.linux.org.uk'; 'linux-arm-
> ker...@lists.infradead.org'
> Subject: RE: [RFC] change non-atomic bitops method
>
> > -Original Message-
> > From: Andrew Morton [mailto:a...@linux-foundation.org]
> > Sent: Tuesday, February 03, 2015 2:39 PM
From: Andrew Morton
Date: Mon, 2 Feb 2015 22:38:51 -0800
> It is only with both these ratios that we can work out whether the
> patch is a net gain. My suspicion is that set_bit on an already-set
> bit is so rare that the patch will be a loss.
A common pattern is implementing a "referenced" bit
ger.kernel.org'; 'li...@arm.linux.org.uk'; 'linux-arm-
> ker...@lists.infradead.org'
> Subject: Re: [RFC] change non-atomic bitops method
>
> On Tue, 3 Feb 2015 13:42:45 +0800 "Wang, Yalin"
> wrote:
> >
> > ...
> >
> > #ifdef CHE
On Tue, 3 Feb 2015 13:42:45 +0800 "Wang, Yalin"
wrote:
>
> ...
>
> #ifdef CHECK_BEFORE_SET
> if (p[i] != times)
> #endif
>
> ...
>
>
> One run on CPU0, reader thread run on CPU1,
> Test result:
> sudo ./cache_test
> reader:8.426228173
> 8.672198335
>
> With -DCHECK_BEF
...@arm.linux.org.uk'; 'linux-arm-
> ker...@lists.infradead.org'
> Subject: RE: [RFC] change non-atomic bitops method
>
> > -Original Message-
> > From: Kirill A. Shutemov [mailto:kir...@shutemov.name]
> > Sent: Tuesday, February 03, 2015 9:18 AM
27;; 'li...@arm.linux.org.uk'; 'linux-arm-
> ker...@lists.infradead.org'
> Subject: Re: [RFC] change non-atomic bitops method
>
> On Mon, Feb 02, 2015 at 03:29:09PM -0800, Andrew Morton wrote:
> > On Mon, 2 Feb 2015 11:55:03 +0800 "Wang, Yalin"
> wrot
On Mon, Feb 02, 2015 at 03:29:09PM -0800, Andrew Morton wrote:
> On Mon, 2 Feb 2015 11:55:03 +0800 "Wang, Yalin"
> wrote:
>
> > This patch change non-atomic bitops,
> > add a if() condition to test it, before set/clear the bit.
> > so that we don't need dirty the cache line, if this bit
> > have
On Mon, Feb 02, 2015 at 03:29:09PM -0800, Andrew Morton wrote:
> On Mon, 2 Feb 2015 11:55:03 +0800 "Wang, Yalin"
> wrote:
>
> > This patch change non-atomic bitops,
> > add a if() condition to test it, before set/clear the bit.
> > so that we don't need dirty the cache line, if this bit
> > have
On Mon, 2 Feb 2015 11:55:03 +0800 "Wang, Yalin"
wrote:
> This patch change non-atomic bitops,
> add a if() condition to test it, before set/clear the bit.
> so that we don't need dirty the cache line, if this bit
> have been set or clear. On SMP system, dirty cache line will
> need invalidate ot
On Mon, Feb 02, 2015 at 11:55:03AM +0800, Wang, Yalin wrote:
> This patch change non-atomic bitops,
> add a if() condition to test it, before set/clear the bit.
> so that we don't need dirty the cache line, if this bit
> have been set or clear. On SMP system, dirty cache line will
> need invalidate
On 2/1/2015 7:55 PM, Wang, Yalin wrote:
This patch change non-atomic bitops,
add a if() condition to test it, before set/clear the bit.
so that we don't need dirty the cache line, if this bit
have been set or clear. On SMP system, dirty cache line will
need invalidate other processors cache line,
This patch change non-atomic bitops,
add a if() condition to test it, before set/clear the bit.
so that we don't need dirty the cache line, if this bit
have been set or clear. On SMP system, dirty cache line will
need invalidate other processors cache line, this will have
some impact on SMP systems
23 matches
Mail list logo
