public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
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

  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