From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Chen Gang <gang.chen@asianux.com>
Cc: josh@freedesktop.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Suggestion] kernel/rcutorture.c: about using scnprintf() instead of sprintf().
Date: Mon, 14 Oct 2013 04:24:58 -0700 [thread overview]
Message-ID: <20131014112457.GN5790@linux.vnet.ibm.com> (raw)
In-Reply-To: <525B555C.3040102@asianux.com>
On Mon, Oct 14, 2013 at 10:22:20AM +0800, Chen Gang wrote:
> On 10/14/2013 09:41 AM, Chen Gang wrote:
> > On 10/13/2013 07:05 PM, Paul E. McKenney wrote:
> >> On Tue, Oct 08, 2013 at 04:32:53PM +0800, Chen Gang wrote:
> >>> Hello Maintainers:
> >>>
> >>> In srcu_torture_stats(), if cpus are more than 1K, the PAGE_SIZE will
> >>> not be enough.
> >>>
> >>> In rcu_torture_printk(), the 'page' maximized size is 4096, it has a
> >>> function pointer for printing, which not tell its maximized length.
> >>>
> >>> Welcome any additional suggestions or completions.
> >>
> >> I never have run rcutorture on a system with that many CPUs. ;-)
> >
> > I guess most of members (include me), never have run under that case.
Indeed, there are not yet very many people with systems that large.
> >> Given that rcutorture is not used in production, my approach would be to
> >> fix this when I encountered it. But what change would you suggest, and,
> >> more importantly, how would you go about testing it before submitting
> >> a patch?
> >>
> >
> > OK, thanks, I will/should give a fix and test.
> >
> > Hmm, In my opinion, we need:
> >
> > - let it pass LTP common simple test (so I can know how to test it).
> >
>
> Oh, after read "Documentation/RCU/torture.txt", it is a test module, so
> except related special test (e.g. shrink maximized buffer), it seems not
> need additional common test for it (e.g. LTP).
Yep!
> > - intend to shrink maximized buffer (PAGE_SIZE -> 64, 256 ..) for test.
This is a good start! However, you should also test the original kernel
to be sure that it really fails. You should of course start by asking
yourself how you would expect it to fail.
What other change should you make to test this in order to be sure that
it will really work when someone tries it on 1024 CPUs? (I am asking
rather than telling because you really need to have this stuff worked
out on your initial submission.)
Another way of thinking about this is to ask yourself the question "If
someone ran rcutorture with torture_type=srcu on a system with 1024 CPUs
(to say nothing of 4096 CPUs), what would they want to happen?" Then:
"How would I test for that on a smaller system?"
> > - read your original mail again (about testing contents) as reference.
> >
> > Excuse me, I have to do some other things of company, so I will/should
> > try to finish it within this week (2013-10-20), if this time point is
> > not quite suitable, please let me know, thanks.
> >
> >> Or if you are simply reporting this as a bug, please let me know that.
> >
> > I will/should do: in q4 of 2013, I will/should spend part of my time
> > resources on testing.
OK, sounds good.
> > Welcome any additional suggestions or completions.
Please see above.
Thanx, Paul
> > Thanks.
> >
>
>
> --
> Chen Gang
>
next prev parent reply other threads:[~2013-10-14 11:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 8:32 [Suggestion] kernel/rcutorture.c: about using scnprintf() instead of sprintf() Chen Gang
2013-10-13 11:05 ` Paul E. McKenney
2013-10-14 1:41 ` Chen Gang
2013-10-14 2:22 ` Chen Gang
2013-10-14 11:24 ` Paul E. McKenney [this message]
2013-10-15 1:40 ` Chen Gang
2013-10-15 8:31 ` Paul E. McKenney
2013-10-15 9:03 ` Chen Gang
2013-10-14 8:38 ` [PATCH] kernel/rcutorture.c: use " Chen Gang
2013-10-14 11:28 ` Paul E. McKenney
2013-10-15 0:54 ` Chen Gang
2013-10-15 1:51 ` Chen Gang
2013-10-15 8:26 ` Paul E. McKenney
2013-10-15 12:32 ` Chen Gang
2013-10-15 14:47 ` Paul E. McKenney
2013-10-16 2:07 ` Chen Gang
2013-10-17 1:06 ` Chen Gang
2013-10-21 5:51 ` [PATCH] kernel/rcutorture.c: be sure of enough memory for result printing Chen Gang
2013-10-21 6:18 ` Chen Gang
2013-10-21 9:35 ` Chen Gang
2013-10-27 14:43 ` Chen Gang
2013-11-04 9:42 ` Chen Gang
2013-11-06 20:38 ` Paul E. McKenney
2013-11-07 2:30 ` [PATCH v2] " Chen Gang
2013-11-07 20:59 ` Paul E. McKenney
2013-11-08 0:58 ` Chen Gang
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=20131014112457.GN5790@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=gang.chen@asianux.com \
--cc=josh@freedesktop.org \
--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 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).