From: Carlos Maiolino <cmaiolino@redhat.com>
To: xfs@oss.sgi.com
Subject: Re: [PATCH] xfstests: src/feature.c: print a number of online CPUs
Date: Mon, 28 Oct 2013 10:23:41 -0200 [thread overview]
Message-ID: <20131028122341.GC2445@orion.maiolino.org> (raw)
In-Reply-To: <526E1108.8070904@oracle.com>
sysconf patch looks ok to me, but, I've never worked with sysconf myself, so,
although the patch looks good for me, I'd prefer Dave to take a deeper look on
it and see if he spot any problem here.
Cheers,
On Mon, Oct 28, 2013 at 11:23:52AM +0400, Stanislav Kholmanskikh wrote:
>
> On 10/25/2013 01:23 AM, Dave Chinner wrote:
> >[ insert comment about not top-posting on mainling lists ]
> >
> >On Thu, Oct 24, 2013 at 11:18:01AM -0200, Carlos Maiolino wrote:
> >>>Actually, I'd say we shoul default to 1 cpu if we can't get the
> >>>number of CPUs. Clearly we have at least one if we can run this
> >>>code. :)
> >>I'm not sure about setting the default to 1 cpu might me a good behavior. My
> >>apologies if I'm saying something wrong, but, if the 'tester' are trying to do
> >>some test trusting on the amount of cpus, it might not be a good behavior.
> >>I was thinking, how about issue an error message if xfstests can't properly
> >>detect the amount of cpus from the system, and add any kind of usage option to
> >>specify the numbers of cpus? So in case of a error while detecting the amount of
> >>cpus.
> >I'd much prefer the test runs with a single CPU as a default rather
> >than not run at all. Most systems the tests run on support these
> >sysconf parameters, so it's going to do what we expect, but quite
> >frankly most tests shoul dnot need to know the number of CPUs.
> >
> >This one is probably misguided, anyway, in what it's doing - if we
> >want to scale the load the test generates, then that's what
> >$LOAD_FACTOR is for. Also, it' multiplies the number of CPUs by 50,
> >then caps the result at 200, so in reality it's only scaling for up
> >to 4 CPUs which doesn't really take into account the range of
> >machines that we test on.
>
> Hi!
>
> Carlos, Dave, so what is the final resolution regarding my patch?
>
> Thank you.
>
> >Cheers,
> >
> >Dave.
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
--
Carlos
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-10-28 12:23 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-23 11:58 Avoid of using /proc/cpuinfo in generic tests Stanislav Kholmanskikh
2013-10-23 11:58 ` [PATCH 1/2] xfstests: implemented _no_of_online_cpus() function Stanislav Kholmanskikh
2013-10-23 13:08 ` Carlos Maiolino
2013-10-23 21:31 ` Dave Chinner
2013-10-24 8:56 ` [PATCH] xfstests: src/feature.c: print a number of online CPUs Stanislav Kholmanskikh
2013-10-24 10:40 ` Dave Chinner
2013-10-24 12:10 ` [PATCH V2] " Stanislav Kholmanskikh
2013-10-28 22:15 ` Dave Chinner
2013-10-29 10:03 ` [PATCH V3] " Stanislav Kholmanskikh
2013-11-05 12:41 ` Stanislav Kholmanskikh
2013-11-10 1:19 ` Rich Johnston
2013-11-10 1:20 ` Rich Johnston
2013-10-24 13:18 ` [PATCH] " Carlos Maiolino
2013-10-24 14:33 ` Stanislav Kholmanskikh
2013-10-24 21:23 ` Dave Chinner
2013-10-28 7:23 ` Stanislav Kholmanskikh
2013-10-28 12:23 ` Carlos Maiolino [this message]
2013-10-23 11:58 ` [PATCH 2/2] xfstests: generic/273: do not use /proc/cpuinfo Stanislav Kholmanskikh
2013-10-23 13:09 ` Carlos Maiolino
2013-10-24 0:14 ` Rich Johnston
2013-10-24 1:09 ` Dave Chinner
2013-11-11 9:34 ` [PATCH] xfstests: generic/273: use src/feature -o Stanislav Kholmanskikh
2013-11-11 11:10 ` Jeff Liu
2013-11-11 16:05 ` Rich Johnston
2013-11-11 16:06 ` Rich Johnston
2013-11-11 14:50 ` [PATCH 2/2] xfstests: generic/273: do not use /proc/cpuinfo Rich Johnston
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=20131028122341.GC2445@orion.maiolino.org \
--to=cmaiolino@redhat.com \
--cc=xfs@oss.sgi.com \
/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.