[lkml]   [2005]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] SMP alternatives
    On Wed, Nov 23, 2005 at 01:53:59PM -0800, H. Peter Anvin wrote:
    > Daniel Jacobowitz wrote:
    > >
    > >I don't think I see the point. This would let you optimize for the
    > >"multi-threaded, but hasn't created any threads yet" or even
    > >"multi-threaded, but not right now" cases. But those really aren't the
    > >interesting case to optimize for - that's the equivalent of supporting
    > >CPU hotplug.
    > >
    > >The interesting case is when you know at static link time that the
    > >library is single-threaded, or even at dynamic link time. And it's
    > >easy enough at both of those times to handle this. In many cases glibc
    > >doesn't, because it's valid to dlopen, but that could be
    > >accomodated - a simple matter of software.
    > >
    > No, you can never know that unless you can't call mmap().

    Please explain what problem you see. If you use mmap to manually load, and patch up its relocations without going to,
    obviously you get to keep both pieces. Or are you talking about
    synchronizing access to shared mmaped buffers?

    This is different from what Linus was talking about precisely because
    we can do it imperatively ("I know this program is single-threaded and
    I'm telling you so" instead of "Hmm, this program hasn't called clone

    It's not as technologically slick but I'd need a lot of convincing to
    believe it wasn't just as useful; and it has the benefit of not
    requiring new silicon.

    Daniel Jacobowitz
    CodeSourcery, LLC
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-11-23 23:05    [W:0.026 / U:29.564 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site