From: Andrew Morton <akpm@linux-foundation.org>
To: "Wang, Yalin" <Yalin.Wang@sonymobile.com>
Cc: "'Kirill A. Shutemov'" <kirill@shutemov.name>,
"'arnd@arndb.de'" <arnd@arndb.de>,
"'linux-arch@vger.kernel.org'" <linux-arch@vger.kernel.org>,
"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
"'linux@arm.linux.org.uk'" <linux@arm.linux.org.uk>,
"'linux-arm-kernel@lists.infradead.org'"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC] change non-atomic bitops method
Date: Tue, 3 Feb 2015 02:59:25 -0800 [thread overview]
Message-ID: <20150203025925.d1c95fb8.akpm@linux-foundation.org> (raw)
In-Reply-To: <35FD53F367049845BC99AC72306C23D1044A02027E0E@CNBJMBX05.corpusers.net>
On Tue, 3 Feb 2015 16:42:14 +0800 "Wang, Yalin" <Yalin.Wang@sonymobile.com> 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_bit_success_count:1096661
> __clear_bit_miss_count:359484 __clear_bit_success_count:3674617
> __test_and_set_bit_miss_count:7 __test_and_set_bit_success_count:221
> __test_and_clear_bit_miss_count:924611 __test_and_clear_bit_success_count:193
>
> __test_and_clear_bit_miss_count has a very high miss rate.
> In fact, I think set/clear/test_and_set(clear)_bit atomic version can also
> Be investigated to see its miss ratio,
> I have not tested the atomic version,
> Because it reside in different architectures.
Hopefully misses in test_and_X_bit are not a problem. The CPU
implementation would be pretty stupid to go and dirty the cacheline
when it knows it didn't change anything. But maybe I'm wrong about
that.
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.
WARNING: multiple messages have this Message-ID (diff)
From: akpm@linux-foundation.org (Andrew Morton)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] change non-atomic bitops method
Date: Tue, 3 Feb 2015 02:59:25 -0800 [thread overview]
Message-ID: <20150203025925.d1c95fb8.akpm@linux-foundation.org> (raw)
In-Reply-To: <35FD53F367049845BC99AC72306C23D1044A02027E0E@CNBJMBX05.corpusers.net>
On Tue, 3 Feb 2015 16:42:14 +0800 "Wang, Yalin" <Yalin.Wang@sonymobile.com> wrote:
> I make a change in kernel to test hit/miss ratio:
Neat, thanks.
>
> ...
>
> After use the phone some time:
> root at D5303:/ # cat /proc/meminfo
> VmallocUsed: 10348 kB
> VmallocChunk: 75632 kB
> __set_bit_miss_count:10002 __set_bit_success_count:1096661
> __clear_bit_miss_count:359484 __clear_bit_success_count:3674617
> __test_and_set_bit_miss_count:7 __test_and_set_bit_success_count:221
> __test_and_clear_bit_miss_count:924611 __test_and_clear_bit_success_count:193
>
> __test_and_clear_bit_miss_count has a very high miss rate.
> In fact, I think set/clear/test_and_set(clear)_bit atomic version can also
> Be investigated to see its miss ratio,
> I have not tested the atomic version,
> Because it reside in different architectures.
Hopefully misses in test_and_X_bit are not a problem. The CPU
implementation would be pretty stupid to go and dirty the cacheline
when it knows it didn't change anything. But maybe I'm wrong about
that.
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.
next prev parent reply other threads:[~2015-02-03 10:59 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-02 3:55 [RFC] change non-atomic bitops method Wang, Yalin
2015-02-02 3:55 ` Wang, Yalin
2015-02-02 18:53 ` Laura Abbott
2015-02-02 18:53 ` Laura Abbott
2015-02-02 19:31 ` Uwe Kleine-König
2015-02-02 19:31 ` Uwe Kleine-König
2015-02-03 15:14 ` David Howells
2015-02-03 15:14 ` David Howells
2015-02-03 15:14 ` David Howells
2015-02-03 19:10 ` Uwe Kleine-König
2015-02-03 19:10 ` Uwe Kleine-König
2015-02-02 23:29 ` Andrew Morton
2015-02-02 23:29 ` Andrew Morton
2015-02-02 23:31 ` Russell King - ARM Linux
2015-02-02 23:31 ` Russell King - ARM Linux
2015-02-03 1:17 ` Kirill A. Shutemov
2015-02-03 1:17 ` Kirill A. Shutemov
2015-02-03 2:13 ` Wang, Yalin
2015-02-03 2:13 ` Wang, Yalin
2015-02-03 5:42 ` Wang, Yalin
2015-02-03 5:42 ` Wang, Yalin
2015-02-03 6:38 ` Andrew Morton
2015-02-03 6:38 ` Andrew Morton
2015-02-03 7:03 ` Wang, Yalin
2015-02-03 7:03 ` Wang, Yalin
2015-02-03 8:42 ` Wang, Yalin
2015-02-03 8:42 ` Wang, Yalin
2015-02-03 10:59 ` Andrew Morton [this message]
2015-02-03 10:59 ` Andrew Morton
2015-02-09 8:18 ` Wang, Yalin
2015-02-09 8:18 ` Wang, Yalin
2015-02-09 20:34 ` Andrew Morton
2015-02-09 20:34 ` Andrew Morton
2015-02-10 7:05 ` Wang, Yalin
2015-02-10 7:05 ` Wang, Yalin
2015-02-09 21:42 ` Rasmus Villemoes
2015-02-09 21:42 ` Rasmus Villemoes
2015-02-09 21:42 ` Rasmus Villemoes
2015-02-03 8:40 ` David Miller
2015-02-03 8:40 ` David Miller
2015-02-03 8:48 ` Andrew Morton
2015-02-03 8:48 ` Andrew Morton
2015-02-03 9:34 ` Rasmus Villemoes
2015-02-03 9:34 ` Rasmus Villemoes
2015-02-03 9:34 ` Rasmus Villemoes
2015-02-03 9:41 ` Wang, Yalin
2015-02-03 9:41 ` Wang, Yalin
2015-02-03 10:39 ` Kirill A. Shutemov
2015-02-03 10:39 ` Kirill A. Shutemov
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=20150203025925.d1c95fb8.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=Yalin.Wang@sonymobile.com \
--cc=arnd@arndb.de \
--cc=kirill@shutemov.name \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.