From: Joerg Vehlow <lkml@jv-coder.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v3] overcommit_memory: Fix unstable subtest
Date: Mon, 30 Nov 2020 09:30:54 +0100 [thread overview]
Message-ID: <01818271-8dba-96a3-76f3-575243c93243@jv-coder.de> (raw)
In-Reply-To: <87360rnuio.fsf@suse.de>
Hi,
>> +static long get_total_batch_size_bytes(void)
>> +{
>> + struct sysinfo info;
>> + long ncpus = tst_ncpus_conf();
> I'm not completely sure if this is the same value as num_cpus_present()
> in the kernel? I'm just wondering if CPU hotplugging could result in the
> wrong value being calculated (other than if it is hotplugged while the test
> is running).
I was thinking about this as well when I implemented this. Here is my
reasoning:
If hotplug is disabled possible=present and possible=nr cpus at boot.
Otherwise present is the real number of existing (not necessarily
enabled cpus), and possible=NR_CPU
In both cases it is the number of cpus installed in the system, enabled
or not.
tst_ncpus_conf is _SC_NPROCESSORS_CONF, which is documented as "returns
the number of processors the operating system configured. But it might
be possible for the operating system to disable individual processors
and so the call", in contrast to _SC_NPROCESSORS_ONLN "returns the
number of processors which are currently online (i.e., available).".
I would interpret _SC_NPROCESSORS_CONF as equal to present and
_SC_NPROCESSORS_ONLN as equal to online.
Anything flaw in my logic?
J?rg
next prev parent reply other threads:[~2020-11-30 8:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-27 7:14 [LTP] [PATCH v3] overcommit_memory: Fix unstable subtest Joerg Vehlow
2020-11-30 8:01 ` Richard Palethorpe
2020-11-30 8:30 ` Joerg Vehlow [this message]
2020-11-30 8:54 ` Richard Palethorpe
2020-12-03 15:30 ` Cyril Hrubis
2020-12-04 5:35 ` Joerg Vehlow
2020-12-11 14:29 ` Cyril Hrubis
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=01818271-8dba-96a3-76f3-575243c93243@jv-coder.de \
--to=lkml@jv-coder.de \
--cc=ltp@lists.linux.it \
/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