wondering why performance tests don't show visible diff. It's quite a big improvement in my local env.

Always on profiling in production (aggregated stack traces from 360-node cluster) does not show any significant time spent in clock_gettime. Maybe it affects only one synthetic query.

Make vDSO kernel mechanism work again to reduce the number of syscalls and to improve performance.

This is not a good changelog entry for users.

Always on profiling in production (aggregated stack traces from 360-node cluster) does not show any significant time spent in clock_gettime.

It also may be something system-specific (kernel version / hw / some settings / etc.)

Maybe it affects only one synthetic query.

Yes, I expect that it should affect queries when nr of blocks is very high, and each block is processed very fast. So mostly every select from zeros/numbers etc. And we have a lot of those in perf tests.

Always on profiling in production

BTW: system.trace_log will tend to catch long-running functions. I.e. shooting a very 'fast target' like system call is much harder than shooting the slow one. We have a very fast system call with almost zero cost, but we have a very high number of those calls.

Lazy initialization in C is often implemented via replacing a pointer to function. I mean we prepare two functions looking like getauxval() - the first with initialization, and the second without. Initially the first function is called, and it replaces the pointer to function to make sure other times the second function will be called. Something like this:

unsigned long __getauxval(unsigned long type)
{
    if (type == AT_SECURE)
        return __auxv_secure;

    if (__auxv)
    {
        size_t index = __find_auxv(type);
        if (index != ((size_t) -1))
            return __auxv[index];
    }

    errno = ENOENT;
    return 0;
}

static void * volatile getauxval_func;

static unsigned long  __auxv_init(unsigned long type)
{
    if (!__environ)
        return 0;

    size_t i;
    for (i = 0; __environ[i]; i++);
    __auxv = (unsigned long *) (__environ + i + 1);

    size_t secure_idx = __find_auxv(AT_SECURE);
    if (secure_idx != ((size_t) -1))
        __auxv_secure = __auxv[secure_idx];

    a_cas_p(&getauxval_func, (void *)__auxv_init, (void *)__getauxval);
    return __getauxval(type);
}

static void * volatile getauxval_func = (void *)__auxv_init;

unsigned long getauxval(unsigned long type)
{
    return ((unsigned long (*)(unsigned long))getauxval_func)(type);
}

Someone breaks test_odbc_interaction/test.py::test_sqlite_odbc_hashed_dictionary in master.
Need to figure out why and where it has been broken.

@filimonov

BTW: system.trace_log will tend to catch long-running functions.

Every function is traced with the probability proportional to the CPU time or real time.

Unfortunately, libunwind does not work correctly with vdso.

This PR is Ok but it interferes with other details in code.

Finally I made it to work.

#28132

This PR is Ok but it interferes with other details in code.

That get us back to the question: can we ensure somehow in tests that vdso path is used? (since it looks like performance tests in CI don't catch that difference),