6:16 p.m.
Hi,
Just a quick question. To determine how many cpu's/cores/channels
the kernel is configured to support, do I need to look at the kernel
source to determine if all of the cores I have are capable of being
used, or is there something else available to tell me without going to
the source?
regards,
Steve
6:44 p.m.
On Tue, Jun 14, 2022 at 5:17 PM Stephen Morris <samorris(a)netspace.net.au> wrote:
Just a quick question. To determine how many
cpu's/cores/channels
the kernel is configured to support, do I need to look at the kernel
source to determine if all of the cores I have are capable of being
used, or is there something else available to tell me without going to
the source?
The values the kernel was configured with are in
/boot/config-<version>. If I understand your question correctly, you
are looking for CONFIG_NR_CPUS, which is 8192 on my machine.
--
Jerry James
http://www.jamezone.org/
11:55 p.m.
On 15/6/22 09:44, Jerry James wrote:
On Tue, Jun 14, 2022 at 5:17 PM Stephen Morris
<samorris(a)netspace.net.au> wrote:
> Just a quick question. To determine how many cpu's/cores/channels
> the kernel is configured to support, do I need to look at the kernel
> source to determine if all of the cores I have are capable of being
> used, or is there something else available to tell me without going to
> the source?
The values the kernel was configured with are in
/boot/config-<version>. If I understand your question correctly, you
are looking for CONFIG_NR_CPUS, which is 8192 on my machine.
Thanks Jerry, I
checked that file and mine is the same as yours, so I
don't need to modify the kernel to use all 16 cores/32 channels for my cpu.
regards,
Steve
8:54 a.m.
On Tue, Jun 14, 2022 at 05:44:27PM -0600, Jerry James wrote:
> Just a quick question. To determine how many
cpu's/cores/channels
> the kernel is configured to support, do I need to look at the kernel
> source to determine if all of the cores I have are capable of being
> used, or is there something else available to tell me without going to
> the source?
The values the kernel was configured with are in
/boot/config-<version>. If I understand your question correctly, you
are looking for CONFIG_NR_CPUS, which is 8192 on my machine.
You can also look at /proc/cpuinfo for what's actually detected — or run
`lscpu` for a more human-readable view (especially when there are a lot of
identical cores!)
Or, `cpu-x` for a GUI view with a lot of detail.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3:41 a.m.
On 22/6/22 23:54, Matthew Miller wrote:
On Tue, Jun 14, 2022 at 05:44:27PM -0600, Jerry James wrote:
>> Just a quick question. To determine how many cpu's/cores/channels
>> the kernel is configured to support, do I need to look at the kernel
>> source to determine if all of the cores I have are capable of being
>> used, or is there something else available to tell me without going to
>> the source?
> The values the kernel was configured with are in
> /boot/config-<version>. If I understand your question correctly, you
> are looking for CONFIG_NR_CPUS, which is 8192 on my machine.
You can also look at /proc/cpuinfo for what's actually detected — or run
`lscpu` for a more human-readable view (especially when there are a lot of
identical cores!)
Or, `cpu-x` for a GUI view with a lot of detail.
Thanks Greg. I installed cpu-x and
tried all the commands. What makes
the first two processes difficult from my perspective is the cpu I have
has 32 treads all of which are the same so the first two processes lists
all 32.
I ran the cpu-x bench marks for random numbers and what was interesting
was the results for 32 threads were only around 16 times the result for
1 thread, which is probably to be expected given the cpu has 16 cores.
regards,
Steve
6:29 a.m.
On Wed, Jun 29, 2022 at 5:43 AM Stephen Morris <samorris(a)netsace.net.au>
wrote:
On 22/6/22 23:54, Matthew Miller wrote:
> [...]
Or, `cpu-x` for a GUI view with a lot of detail.
Thanks Greg. I installed cpu-x and tried all the commands. What makes
the first two processes difficult from my perspective is the cpu I have
has 32 treads all of which are the same so the first two processes lists
all 32.
I ran the cpu-x bench marks for random numbers and what was interesting
was the results for 32 threads were only around 16 times the result for
1 thread, which is probably to be expected given the cpu has 16 cores.
My experience was that disabling hyperthreading didn't reduce throughput.
These multi-core systems generally do better with integer workloads, I
think some
have one f.p. unit per core. There can be very counterintuitive
performance
changes due to CPU cache issues and communications overhead. My experience
is mostly with I/O intensive workloads. We generally found it best to
limit those tasks
to a fraction of the cores so background tasks (job control/monitoring,
backups, etc)
didn't stall. After a big effort to make efficient use of all the cores
you may
encounter thermal throttling. It was better to adjust the workload to
avoid
thermal issues: more consistent thruput and fewer issues with background
tasks.
--
George N. White III
7:14 a.m.
If you have cache stalls in the algorithm/benchmark and/or io sections
that have to be waited on then hyperthreading will usually help.
If the code is a nice tight loop that correctly/full uses the cpu with
minimal cache stalls then hyperthreading will hurt.
I was doing some benchmarks and kind of accidentally found out that if
you run 1 single cpu benchmark on an idle system (36 real cores)
disabling hyperthreading on the system and/or pinning the benchmark to
a cpu with that cpus specific hypertread being offline (finding the
cpu in /sys and echoing 0 to online to disable it) resulted in a
consistent measurable speed up (1-2% I think was the amount) on a idle
system. The cost of the ht simply existing was a 1-2% of less work
being done by the primary thread because the ht caused the primary
thread to be inefficient in some manner (stolen cache and/or stolen
cpu cycles).
On the newer cpus Intel is using thermal throttling to determine how
hard it can push the turboboost frequencies, so thermal throttling is
expected and is not a concern. And when I was testing several
different sockets+memory each cpu/socket seemed to thermal throttle at
different frequencies (all well above the rated frequency, but some
sockets were always a few % faster than others and a few % higher
frequencies before thermal throttling). I also noticed that the
frequency the cpu could obtain consistently at the edge of thermal
throttling seem to be different (as would be expected) based on the
benchmark. Simple benchmarks went all of the way to the max
turboboost frequency (+600Mhz), and other benchmarks only allowed
+200Mhz over rated before overheating and reducing turboboost.
On Wed, Jun 29, 2022 at 6:32 AM George N. White III <gnwiii(a)gmail.com> wrote:
>
> On Wed, Jun 29, 2022 at 5:43 AM Stephen Morris <samorris(a)netsace.net.au>
wrote:
>>
>> On 22/6/22 23:54, Matthew Miller wrote:
>> > [...]
>>
>> > Or, `cpu-x` for a GUI view with a lot of detail.
>> Thanks Greg. I installed cpu-x and tried all the commands. What makes
>> the first two processes difficult from my perspective is the cpu I have
>> has 32 treads all of which are the same so the first two processes lists
>> all 32.
>> I ran the cpu-x bench marks for random numbers and what was interesting
>> was the results for 32 threads were only around 16 times the result for
>> 1 thread, which is probably to be expected given the cpu has 16 cores.
>
>
> My experience was that disabling hyperthreading didn't reduce throughput.
> These multi-core systems generally do better with integer workloads, I think some
> have one f.p. unit per core. There can be very counterintuitive performance
> changes due to CPU cache issues and communications overhead. My experience
> is mostly with I/O intensive workloads. We generally found it best to limit those
tasks
> to a fraction of the cores so background tasks (job control/monitoring, backups,
etc)
> didn't stall. After a big effort to make efficient use of all the cores you may
> encounter thermal throttling. It was better to adjust the workload to avoid
> thermal issues: more consistent thruput and fewer issues with background tasks.
>
>
> --
> George N. White III
>
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
6:42 p.m.
On 29/6/22 22:14, Roger Heflin wrote:
If you have cache stalls in the algorithm/benchmark and/or io
sections
that have to be waited on then hyperthreading will usually help.
If the code is a nice tight loop that correctly/full uses the cpu with
minimal cache stalls then hyperthreading will hurt.
I was doing some benchmarks and kind of accidentally found out that if
you run 1 single cpu benchmark on an idle system (36 real cores)
disabling hyperthreading on the system and/or pinning the benchmark to
a cpu with that cpus specific hypertread being offline (finding the
cpu in /sys and echoing 0 to online to disable it) resulted in a
consistent measurable speed up (1-2% I think was the amount) on a idle
system. The cost of the ht simply existing was a 1-2% of less work
being done by the primary thread because the ht caused the primary
thread to be inefficient in some manner (stolen cache and/or stolen
cpu cycles).
On the newer cpus Intel is using thermal throttling to determine how
hard it can push the turboboost frequencies, so thermal throttling is
expected and is not a concern. And when I was testing several
different sockets+memory each cpu/socket seemed to thermal throttle at
different frequencies (all well above the rated frequency, but some
sockets were always a few % faster than others and a few % higher
frequencies before thermal throttling). I also noticed that the
frequency the cpu could obtain consistently at the edge of thermal
throttling seem to be different (as would be expected) based on the
benchmark. Simple benchmarks went all of the way to the max
turboboost frequency (+600Mhz), and other benchmarks only allowed
+200Mhz over rated before overheating and reducing turboboost.
I have an AMD Ryzen
9 5980X cpu with overclocking not set in the
motherboard bios so I haven't done any tests on how far I can push the
cpu before thermal limitations start to kick in.
Also I had only just installed cpu-x for the first time and I was just
testing it out to see what it produced.
I also have an ASUS Nvidia RTX 3080 graphics card with 12GB of memory
which I have run the 3D Mark and Unigine Heaven benchmark on to see what
they produce, and what was interesting with the 3D Mark test was, either
3D Mark was doing something funny with its 2nd graphics test or that
graphics card couldn't handle it, as instead of showing the video like
it did for the first test it started to show the same video then almost
immediately changed it to show what I can only describe as floating
bubbles on a black background.
With the Unigine Benchmark running the graphics card (as measured by
Unigine) sat at around 78C to 79C, which is will within tolerances.
regards,
Steve
regards,
Steve
On Wed, Jun 29, 2022 at 6:32 AM George N. White III <gnwiii(a)gmail.com> wrote:
> On Wed, Jun 29, 2022 at 5:43 AM Stephen Morris <samorris(a)netsace.net.au>
wrote:
>> On 22/6/22 23:54, Matthew Miller wrote:
>>> [...]
>>> Or, `cpu-x` for a GUI view with a lot of detail.
>> Thanks Greg. I installed cpu-x and tried all the commands. What makes
>> the first two processes difficult from my perspective is the cpu I have
>> has 32 treads all of which are the same so the first two processes lists
>> all 32.
>> I ran the cpu-x bench marks for random numbers and what was interesting
>> was the results for 32 threads were only around 16 times the result for
>> 1 thread, which is probably to be expected given the cpu has 16 cores.
>
> My experience was that disabling hyperthreading didn't reduce throughput.
> These multi-core systems generally do better with integer workloads, I think some
> have one f.p. unit per core. There can be very counterintuitive performance
> changes due to CPU cache issues and communications overhead. My experience
> is mostly with I/O intensive workloads. We generally found it best to limit those
tasks
> to a fraction of the cores so background tasks (job control/monitoring, backups,
etc)
> didn't stall. After a big effort to make efficient use of all the cores you may
> encounter thermal throttling. It was better to adjust the workload to avoid
> thermal issues: more consistent thruput and fewer issues with background tasks.
>
>
> --
> George N. White III
>
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
6:22 p.m.
On 29/6/22 21:29, George N. White III wrote:
On Wed, Jun 29, 2022 at 5:43 AM Stephen Morris
<samorris(a)netsace.net.au> wrote:
On 22/6/22 23:54, Matthew Miller wrote:
> [...]
> Or, `cpu-x` for a GUI view with a lot of detail.
Thanks Greg. I installed cpu-x and tried all the commands. What makes
the first two processes difficult from my perspective is the cpu I
have
has 32 treads all of which are the same so the first two processes
lists
all 32.
I ran the cpu-x bench marks for random numbers and what was
interesting
was the results for 32 threads were only around 16 times the
result for
1 thread, which is probably to be expected given the cpu has 16 cores.
My experience was that disabling hyperthreading didn't reduce throughput.
These multi-core systems generally do better with integer workloads, I
think some
have one f.p. unit per core. There can be very counterintuitive
performance
changes due to CPU cache issues and communications overhead. My
experience
is mostly with I/O intensive workloads. We generally found it best to
limit those tasks
to a fraction of the cores so background tasks (job
control/monitoring, backups, etc)
didn't stall. After a big effort to make efficient use of all the
cores you may
encounter thermal throttling. It was better to adjust the workload
to avoid
thermal issues: more consistent thruput and fewer issues with
background tasks.
Thanks George, I have experienced the same things myself. Having
installed cpu-x for the first time I was just trying it out, and it
default benchmark mode was 1 minute and 1 thread with slow random number
generation and fast random number generation, I haven't done any
investigation to determine exactly what that means. So a ran a test on
the default setting, then ran a test on 32 threads which returned a
result that was around 16 times the results from a single thread. Which
I was not surprised at as being a 16 core dual channel cpu, and hence
Windows and Fedora consider it to have 32 logical cores, it doesn't
matter how many channel are available for each core the total throughput
is only what a core is capable of producing.
regards,
Steve
--
George N. White III
_______________________________________________
users mailing list --users(a)lists.fedoraproject.org
To unsubscribe send an email tousers-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/users@lists.fedora...
Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
699
days inactive
714
days old
8 comments
5 participants
participants (5)
-
George N. White III -
Jerry James -
Matthew Miller -
Roger Heflin -
Stephen Morris