All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v3] overcommit_memory: Fix unstable subtest
Date: Mon, 30 Nov 2020 08:54:44 +0000	[thread overview]
Message-ID: <87zh2zmdgr.fsf@suse.de> (raw)
In-Reply-To: <01818271-8dba-96a3-76f3-575243c93243@jv-coder.de>

Hello,

Joerg Vehlow <lkml@jv-coder.de> writes:

> 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

This sounds correct, it would be strange if _SC_NPROCESSORS_CONF
returned num_possible_cpus().

-- 
Thank you,
Richard.

  reply	other threads:[~2020-11-30  8:54 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
2020-11-30  8:54     ` Richard Palethorpe [this message]
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=87zh2zmdgr.fsf@suse.de \
    --to=rpalethorpe@suse.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 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.