From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Alexander Gordeev <agordeev@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/9] rcu: Cleanup rcu_init_geometry() code and arithmetics
Date: Sat, 7 Mar 2015 13:47:02 -0800 [thread overview]
Message-ID: <20150307214702.GP5236@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150307185954.GB15033@agordeev.usersys.redhat.com>
On Sat, Mar 07, 2015 at 06:59:54PM +0000, Alexander Gordeev wrote:
> On Sat, Mar 07, 2015 at 10:08:21AM -0800, Paul E. McKenney wrote:
> > The rest of this series looks promising, but I do have to ask... How have
> > you tested these? The most straightforward approach would be to find
>
> I tried trees with 1,2 and 3 levels on a 160-CPU machine + dozens of kernel
> builds with 'make -j160'. I feel bit guilty I did not try the corner case
> with 4 levels, but run-time-wise it is not really differ from what I done.
>
> Do you expect the below is a better option?
What you did is not bad, actually. You can get four levels by building
with both CONFIG_RCU_FANOUT and CONFIG_RCU_FANOUT_LEAF equal to five,
and that will also test non-power-of-two choices. You do that, and I
will give your series a shot.
What I need to do is to create a user-level test that does the full
exhaustive test, varying:
o NR_CPUS from 1 to 4096
o nr_cpu_ids from 1 to NR_CPUS
o CONFIG_RCU_FANOUT from 2 to 64
o CONFIG_RCU_FANOUT_LEAF from 2 to 64
o CONFIG_RCU_FANOUT_EXACT from n to y
Unfortunately, if each test case took one millisecond, this would take
two years. Not so good when a new version of Linux comes out every
couple of months. Of course, this could be paralellized, but still...
So I should focus on the values actually used, especially for NR_CPUS:
o NR_CPUS from 1 to 4096 by powers of two, for 13 combinations
o nr_cpu_ids from 1 to NR_CPUS
o CONFIG_RCU_FANOUT of 32 or 64
o CONFIG_RCU_FANOUT_LEAF of 16, 32, or 64
o CONFIG_RCU_FANOUT_EXACT of n or y
This is 268,435,452 test cases, which is about tree days at one
millisecond per case. (My current single-use manual-inspection test
takes eight milliseconds, but then again it is printing out tons of
stuff.) But I do need to add at least a few oddball values -- there
was a bug for some years that happened only with CONFIG_RCU_FANOUT and
CONFIG_RCU_FANOUT_LEAF not dividing evenly.
Or maybe I can use cbmc and make things faster.
Anyway, again, if you do the test with CONFIG_RCU_FANOUT and
CONFIG_RCU_FANOUT_LEAF equal to five, this user-level testing is my
problem rather than yours.
Thanx, Paul
> > a KVM-capable system with at least 16 CPUs and type the following from
> > the top-level directory:
> >
> > sh tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 34 --duration 5
> >
> > This will do a series of 16 build-boot-test cycles with various configs
> > (including various rcu_node tree shapes), and print a summary of the
> > outcome at the end.
> >
> > For these sorts of changes, I usually also do some user-level testing.
>
>
> --
> Regards,
> Alexander Gordeev
> agordeev@redhat.com
>
next prev parent reply other threads:[~2015-03-07 21:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-07 17:03 [PATCH 0/9] rcu: Cleanup RCU tree initialization Alexander Gordeev
2015-03-07 17:03 ` [PATCH 1/9] rcu: Panic if RCU tree can not accommodate all CPUs Alexander Gordeev
2015-03-07 17:42 ` Paul E. McKenney
2015-03-07 18:48 ` Alexander Gordeev
2015-03-07 21:52 ` Paul E. McKenney
2015-03-07 17:03 ` [PATCH 2/9] rcu: Remove superfluous local variable in rcu_init_geometry() Alexander Gordeev
2015-03-07 18:03 ` Paul E. McKenney
2015-03-07 17:03 ` [PATCH 3/9] rcu: Cleanup rcu_init_geometry() code and arithmetics Alexander Gordeev
2015-03-07 18:08 ` Paul E. McKenney
2015-03-07 18:59 ` Alexander Gordeev
2015-03-07 21:47 ` Paul E. McKenney [this message]
2015-03-07 17:03 ` [PATCH 4/9] rcu: Simplify rcu_init_geometry() capacity arithmetics Alexander Gordeev
2015-03-07 17:03 ` [PATCH 5/9] rcu: Limit rcu_state::levelcnt[] to RCU_NUM_LVLS items Alexander Gordeev
2015-03-07 17:03 ` [PATCH 6/9] rcu: Limit rcu_capacity[] size " Alexander Gordeev
2015-03-07 17:03 ` [PATCH 7/9] rcu: Remove unnecessary fields from rcu_state structure Alexander Gordeev
2015-03-07 17:03 ` [PATCH 8/9] rcu: Limit count of static data to the number of RCU levels Alexander Gordeev
2015-03-07 17:03 ` [PATCH 9/9] rcu: Simplify arithmetic to calculate number of RCU nodes Alexander Gordeev
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=20150307214702.GP5236@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=agordeev@redhat.com \
--cc=linux-kernel@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 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.