Date: Thu, 29 Jun 2023 20:18:31 +0200
From: Michael van Elst <mlel...@serpens.de>
Message-ID: <zj3k926atknfx...@serpens.de>
| Unless there is a BIAS on those numbers and the real values are maybe 15
| degrees higher.
Probably 20. That would be more realistic.
| I can also easily imagine that temperatures rise with enabled turbo
| mode, even when idle, in particular on selected dies like the i9-12900ks.
Rise yes, but keep on rising over time? This is a new thing I am just
seeing in the past month or so, until then this system was very stable.
| The code is supposed to follow the Linux example. If a fixed Tjmax can
| be read, then that's it. If no fixed Tjmax can be read, a dynamic value
| needs to be read from a new register every time you evaluate the
temperature.
Yes, apologies - I misread the patch (I have actually looked more at the
patched file since ...). That is what it is doing. It is perhaps even
doing (or would be if used on the relevant processors) a bit more of that
than it should be - I doubt there are processor versions which give an
fault when reading one of those registers at one attempt, and then work
the next time.
| N.B. Asrock says, they would configure Tjmax to 105C for that board.
That doesn't seem to be what they have done. Or the people who built the
system for me perhaps were meant to, and didn't know to do that.
But I have some things to try now, more information to obtain. I will do that
later tonight and send another message later.
| That happens when that cpu is used by another LWP (maybe a kernel thread
| that is bound to that cpu) and the previously running LWP needs to be
| migrated.
Ah, thanks - that explains what is happening, though isn't really
the way I'd like to see things on this system (though it would make
sense on a system with homogenous CPUs). I think I'd like to try
limiting the kernel threads to the highest numbered (perhaps 4) of
the performance cores - those should be plenty fast enough, and lots
of systems only have 4 cores, so it should be sufficient. Then
processes can use the faster performance cores, and the slower economy
cores, with less risk of being needlessly bumped.
| It has no idea what a "suitable CPU" is.
Yes, I know - that is something that will need code added, somewhere,
to provide the information. It could be done as a note in the binary
file for processes that need high performance (usually) - like perhaps
gcc (and clang) (or the relevant part of those), and ffmpeg, and things
like that, and have all the "normal" processes default to the low speed
cores (which are still fast by most standards) unless there are none free
and a performance core is available.
Or better, monitoring the processes dynamically, looking for those which
get bumped due to time quantum exceeded without doing (at least, slow)
system calls, or lots of fast ones perhaps, and promote those to faster
cores, so they will get more done each time they get to run - and then
watch processes on those cores, and if they start blocking in system calls,
more often then exceeding the time quantum, then move them to slower cores.
The actual algorithms would need more thought than this 5 mins worth, and
then evaluation for a while to see how the perform under varying loads.
| With our simple scheduler strategy that loads one thread per core and
| only puts two threads on each core when you have more runnable threads
| (except for the bound system threads).
Yes, that would probably help a bit - though liking a core and its
hyperthread clone to threads from the same process might be a good
idea.
| On Intel however (at least on this i5), the mapping alternates between
| both threads:
On all Intel processors with hyperthreading that I have seen. This is
the first one I have bought that has had that, I typically looked for a
processor without it, just to avoid the nuisance, but there was nothing
available in the same class as this processor without it (slower ones of
the same generation, but not this).
kre
