This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [glibc] Fix Linux sysconf(_SC_NPROCESSORS_[CONF|ONLN])performance problem


On Fri, Jun 17, 2011 at 1:14 AM, Klaus Dittrich <kladit@arcor.de> wrote:
>
> As, at least today, most users run with a constant number of cpus,
> how about a configure option like num_of_cpus_may_vary in either kernel or
> glibc.
>
> This would give the time to discuss calmly a better solution for the others.

I really think that Paul's suggestion is so simple that it's not even
worth worrying about it.

Do the caching (because doing an open/read/close is always going to be
relatively expensive, and libdb seems to literally do it thousands of
times), but together with the cached value you just associate the
current time. "gettimeofday()" is about as cheap of a system call that
there is.

So the wrapper function could trivially do something like this:

  long
  __get_nprocs()
  {
    static long cache;
    static time_t sec;
    timeval tv;
    long ret;

    gettimeofday(&tv, NULL);
    ret = cache;
    read_barrier();
    if (ret < 0 || tv.tv_sec != sec)
      {
        ret = __do_slow_get_nprocs();
        sec = tv.sec;
        write_barrier();
        cache = ret;
      }
    return ret;
  }

and caching doesn't get much simpler than that. It's even thread-safe
with the barriers (multiple threads might all do the slow-case and
update the cache, and mix things up, but they'll never do anything
bad).

                            Linus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]