[lkml]   [2008]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: pthread_create() slow for many threads; also time to revisit 64b context switch optimization?

    * Ulrich Drepper <> wrote:

    > Hash: SHA1
    > Ingo Molnar wrote:
    > > i find it pretty unacceptable these days that we limit any aspect of
    > > pure 64-bit apps in any way to 4GB (or any other 32-bit-ish limit).
    > Sure, but if we can pin-point the sub-archs for which it is the
    > problem then a flag to optionally request it is even easier to handle.
    > You'd simply ignore the flag for anything but the P4 architecture.

    i suspect you are talking about option #2 i described. It is the option
    which will take the most time to trickle down to people.

    > I personally have no problem removing the whole thing because I have
    > no such machine running anymore. But there are people out there who
    > have.

    hm, i think the set of people running on such boxes _and_ then upgrading
    to a new glibc and expecting everything to be just as fast to the
    microsecond as before should be miniscule. Those P4 derived 64-bit boxes
    were astonishingly painful in 64-bit mode - most of that hw is running
    32-bit i suspect, because 64-bit on it was really a joke.

    Btw., can you see any problems with option #1: simply removing MAP_32BIT
    from 64-bit stack allocations in glibc unconditionally? It's the fastest
    to execute and also the most obvious solution. +1 usecs overhead in the
    64-bit context-switch path on those old slow boxes wont matter much.

    10 _millisecs_ to start a single thread on top-of-the-line hw is quite
    unaccepable. (and there's little sane we can do in the kernel about
    allocation overhead when we have an imperfectly filled 4GB box for all


     \ /
      Last update: 2008-08-13 17:45    [W:0.021 / U:12.564 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site