[lkml]   [2006]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [discuss] Re: FOR REVIEW: New x86-64 vsyscall vgetcpu()
    On Wednesday 14 June 2006 18:30, Ulrich Drepper wrote:
    > > Eventually we'll need a dynamic format but I'll only add it
    > > for new calls that actually require it for security.
    > > vgetcpu doesn't need it.
    > Just introduce the vdso now, add all new vdso calls there. There is no
    > reason except laziness to continue with these moronic fixed addresses.
    > They only get in the way of address space layout change/optimizations.

    The user address space size on x86-64 is final (baring the architecture gets extended
    to beyond 48bit VA). We already use all positive
    space. But the vsyscalls don't even live in user address space.

    > >>> long vgetcpu(int *cpu, int *node, unsigned long *tcache)
    > >> Do you expect the value returned in *cpu and*node to require an error
    > >> value? If not, then why this fascination with signed types?
    > >
    > > Shouldn't make a difference.
    > If there is no reason for a signed type none should be used. It can
    > only lead to problems.

    Ok i can change it to unsigned if you feel that strongly about it.

    > This reminds me: what are the values for the CPU number? Are they
    > continuous? Are they the same as those used in the affinity syscalls
    > (they better be)?

    Yes of course.

    > With hotplug CPUs, are CPU numbers "recycled"?

    I think if the same CPU gets unplugged and replugged it should
    get the same number. Otherwise new numbers should be allocated.

    > Yes, in this one case
    > you might at this point in time only need two words. But
    > - this might change

    Alan suggested adding some padding which probably
    makes sense, although I frankly don't see the implementation
    changing. Variable length would be clear overkill and I refuse
    to overdesign this.

    > - there might be other future functions in the vdso which need memory.
    > It is a huge pain to provide more and more of these individual
    > variables. Better allocate one chunk.

    Why is it a problem? It's just var __thread isn't it?

    > > If some other function needs a cache too it can define its own.
    > > I don't see any advantage of using a shared buffer.
    > I believe it that _you_ don't see it. Because the pain is in the libc.
    > The code to set up stack frames has to be adjusted for each new TLS
    > variable. It is better to do it once in a general way which is what I
    > suggested.

    Hmm, I thought user space could define arbitary own __threads. I certainly
    used that in some of my code. Why is it a problem for the libc to do the same?

    Anyways even if it's such a big problem you can put it all in
    one chunk and partition it yourself given the fixed size. I don't think
    the kernel code should concern itself about this.

    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: 2006-06-14 19:37    [W:0.022 / U:28.168 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site