Friday, May 12, 2023

Digest for comp.lang.c++@googlegroups.com - 11 updates in 2 topics

Jehangir Iqbal <jehangir.iqbal@gmail.com>: May 12 03:09PM -0700

Hi,
 
I have been working on RocksDB (https://github.com/facebook/rocksdb) and I am running into a problem while building the binaries on Amazon Linux EC2 instance of type i3.8xlarge.
 
There is a class called Performance Context. It provides time spent in nano seconds in different operations.
 
There are some unit tests that test this functionality. The functionality uses the following code to calculate the nano seconds spent in the thread.
 
uint64_t CPUNanos() override {
struct timespec ts;
clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts);
return static_cast<uint64_t>(ts.tv_sec) * 1000000000 + ts.tv_nsec;
}
 
On EC2 instance of type i3.8xlarge, some times the time reported is 0 nano seconds. The operation has gone through disk and memory operations so I know the time is not really 0 nano seconds.
 
I assumed that this is happening because the thread is switched between CPUs. To confirm my assumption, I have wrote a simple program as shown below
 
#include <iostream>
#include <time.h>
#include <sched.h>
#include <unistd.h>
#include <utility>
 
uint64_t getNanoSecCPUTime() {
struct timespec ts;
clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts);
return static_cast<uint64_t>(ts.tv_sec) * 1000000000 + ts.tv_nsec;
}
 
int main() {
 
auto iterations = 10'000;
auto count = 0;
auto nanoSec = getNanoSecCPUTime();
for (int i = 0; i < iterations; i++) {
auto newNanoSec = getNanoSecCPUTime();
 
for (auto k=0; k<1'000;k++) {
auto assign = k;
}
 
if (nanoSec == newNanoSec) {
std::cout << nanoSec << ":" << newNanoSec << std::endl;
count++;
}
nanoSec = newNanoSec;
}
std::cout << "Matched " << count << " times." << std::endl;
}
 
This program checks that how many times the nano seconds are reported as same between two calls. It has variable output, sometimes the nanoseconds match 3000+ times, sometimes they match 10 times etc.
 
I have taken all the CPUs offline using this command for CPU from 1 to 31
 
echo 0 > /sys/devices/system/cpu/cpuN/online
 
After that the program never reports any matching values.
 
I have following questions
* Is it possible that there is genuinely zero nano seconds passed between two calls?
* Is the call to clock_gettime with CLOCK_THREAD_CPUTIME_ID is a reliable way to measure thread time. If not, what can be done?
 
Note: If I replace CLOCK_THREAD_CPUTIME_ID with CLOCK_MONOTONIC, rocks DB build passes all unit tests and also my program passes as well.
Bonita Montero <Bonita.Montero@gmail.com>: May 12 03:43AM +0200

Am 11.05.2023 um 19:18 schrieb Scott Lurndal:
 
> Linux only overcommits if the administrator configures it to
> overcommit. ...
 
This is the default-behaviour which is almost never changed.
Muttley@dastardlyhq.com: May 12 09:01AM

On Thu, 11 May 2023 16:06:51 GMT
>>to need that memory very soon anyway such as in a DBMS.
 
>I spent a fair amount of time in the Oracle RDBMS internals. They
>never used realloc. Or malloc, for that matter.
 
Doesn't surprise me, Oracle is virtually an OS in its own right. It doesn't
(or didn't) usually use any of the built in filesystems either, prefering to
be given one or more raw partitions which it then did its own thing with. On
*nix anyway, don't know about Windows.
Bonita Montero <Bonita.Montero@gmail.com>: May 12 11:06AM +0200


> Doesn't surprise me, Oracle is virtually an OS in its own right. ...
 
Oracle does nothing a kernel does.
 
> It doesn't (or didn't) usually use any of the built in filesystems
> either, prefering to be given one or more raw partitions ...
 
The data warehousing guide says the performance advantage of using
raw filesystems is 3% to 5% and using a normal filesytem has a lot
of advantages. I think almost any DBA choses a filesystem (I'm a
certified OCP-DBA).
scott@slp53.sl.home (Scott Lurndal): May 12 01:16PM


>> Linux only overcommits if the administrator configures it to
>> overcommit. ...
 
>This is the default-behaviour which is almost never changed.
 
And you base your opinion on what experiences, exactly?
Bonita Montero <Bonita.Montero@gmail.com>: May 12 07:01PM +0200

Am 12.05.2023 um 15:16 schrieb Scott Lurndal:
>>> overcommit. ...
 
>> This is the default-behaviour which is almost never changed.
 
> And you base your opinion on what experiences, exactly?
 
It's required for forking software which is still common. Otherwise
you'd have to reserve a large amount of swap which is actually never
used.
And there's only one small discussion on Stack Exchange about that.
scott@slp53.sl.home (Scott Lurndal): May 12 05:58PM

>you'd have to reserve a large amount of swap which is actually never
>used.
>And there's only one small discussion on Stack Exchange about that.
 
Stack exchange? Not representative of production unix or linux system
operations, that's certain.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: May 12 12:13PM -0700

>>> overcommit. ...
 
>>This is the default-behaviour which is almost never changed.
 
> And you base your opinion on what experiences, exactly?
 
I had thought about commenting on this myself.
 
In my experience, which is certainly not exhaustive, most Linux systems
have overcommit enabled by default. I've never seen one where it's
disabled (though I haven't always checked).
 
On my Ubuntu system, `cat /proc/sys/vm/overcommit_memory` shows 0,
which according to the proc(5) man page means:
 
In mode 0, calls of mmap(2) with MAP_NORESERVE are not checked, and
the default check is very weak, leading to the risk of getting a
process "OOM-killed".
 
Have you seen it set by default to a different value? (This is
admittedly only marginally topical, but it does affect the behavior of
memory allocation in C++ programs.)
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
Bonita Montero <Bonita.Montero@gmail.com>: May 12 09:27PM +0200

Am 12.05.2023 um 19:58 schrieb Scott Lurndal:
 
> Stack exchange? Not representative of production unix or linux system
> operations, that's certain.
 
Stack Exchange is the most qualified source for such discussions
because they delete unqualified comments.
scott@slp53.sl.home (Scott Lurndal): May 12 09:12PM

>> operations, that's certain.
 
>Stack Exchange is the most qualified source for such discussions
>because they delete unqualified comments.
 
Now that is truely self-referential. Sigh.
scott@slp53.sl.home (Scott Lurndal): May 12 09:18PM


>Have you seen it set by default to a different value? (This is
>admittedly only marginally topical, but it does affect the behavior of
>memory allocation in C++ programs.)
 
All of our simulation systems (many hundred linux servers) run with
overcommit set to 2 (always check). They're running RTL simulations
and it's much better to prevent a long-running simulation from starting rather
than killing one randomly after a few hours of cpu time.
 
The queue management system that distributes jobs to the servers
understands the server capacities and trusts the user's estimate
of required memory, but those estimates are often faulty.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.

No comments: