Re: [9fans] Plan 9 and multicores/parallelism/concurrency? - Plan9

This is a discussion on Re: [9fans] Plan 9 and multicores/parallelism/concurrency? - Plan9 ; // But do you know of any part [of Plan 9] that would be // beneficial for highly-SMP systems? Beneficial compared to what, I guess. I agree with your comment that most of the pressure is on the application rather ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Re: [9fans] Plan 9 and multicores/parallelism/concurrency?

  1. Re: [9fans] Plan 9 and multicores/parallelism/concurrency?

    // But do you know of any part [of Plan 9] that would be
    // beneficial for highly-SMP systems?

    Beneficial compared to what, I guess. I agree with your
    comment that most of the pressure is on the application
    rather than the kernel. The kernel's biggest contribution here
    is keeping processes inexpensive compared to unix. As for the
    system overall, there's something to be said for decomposing
    problems to interfaces that can be represented in the
    namespace; then, to a large extent, it doesn't matter whether
    we're talking about one box or many.

    // On the other hand, may be the trick is not to scale a single
    // kernel on something like that but have multiple kernels
    // running under something like Xen or kvm.

    There's certainly something to be said for this in many cases,
    but it hardly takes away any burden from application
    developers. They've just got more practice doing it for logically
    distinct machines. It lets kernel developers off the hook, but
    I'm not sure that's a good thing.

    // It'll be interesting to see how a single Plan9 kernel scales on
    // something like a Batoka box (256 hardware threads per box,
    // 64 physical cores).

    Send me one and I'll see if I can find out. ☺

    Anthony



  2. Re: [9fans] Plan 9 and multicores/parallelism/concurrency?

    > // But do you know of any part [of Plan 9] that would be
    > // beneficial for highly-SMP systems?


    one difference from many of the others is that plan 9, both kernel and applications,
    were written with multiprocessors in mind, at least up to 32 or so, so data structure
    locking was included as the code was written, and processes (kprocs in the kernel)
    were used (or not) as appropriate. generally, the granularity used seems appropriate.
    kernel processes can be pre-empted. there is plenty of scope for parallelism.

    many others started with a non-preemptible kernel and added a big global lock,
    and gradually, very gradually changed code to use locks at finer granularity.
    sometimes.



  3. Re: [9fans] Plan 9 and multicores/parallelism/concurrency?

    On Mon, 2008-07-14 at 16:08 -0400, a@9srv.net wrote:
    > // But do you know of any part [of Plan 9] that would be
    > // beneficial for highly-SMP systems?
    >
    > Beneficial compared to what, I guess.


    Lets say a typical Linux kernel.

    > The kernel's biggest contribution here is keeping processes inexpensive
    > compared to unix.


    Not just inexpensive, but also better aligned with how
    they use compute resources (virtual vs. physical threads)
    and memory resources.

    > // It'll be interesting to see how a single Plan9 kernel scales on
    > // something like a Batoka box (256 hardware threads per box,
    > // 64 physical cores).
    >
    > Send me one and I'll see if I can find out. ☺


    Speaking of which -- is SPARC port of Plan9 still alive?

    Thanks,
    Roman.



  4. Re: [9fans] Plan 9 and multicores/parallelism/concurrency?

    // Not just inexpensive, but also better aligned with how
    // they use compute resources (virtual vs. physical threads)
    // and memory resources.

    Hrm. I know about the memory/cache issues, but it sounds
    like there's more on the CPU side I don't know much about.
    Is there more here beyond the memory question and
    prediction/pipelining?

    I'm reading the PDF you referenced now.

    // Speaking of which -- is SPARC port of Plan9 still alive?

    Not really. There's a partially-working sparc64 port out there
    which ran on the Ultra 1 (I think), but it's neither been kept up
    to date nor made to run on anything beyond that. A few folks
    (including myself) have poked at it a bit with varying results,
    none of which were particularly good.

    Something on Batoka would provide better motivation than my
    old Ultra 5, though!

    Anthony



  5. Re: [9fans] Plan 9 and multicores/parallelism/concurrency?

    On Mon, 2008-07-14 at 18:12 -0400, a@9srv.net wrote:
    > // Not just inexpensive, but also better aligned with how
    > // they use compute resources (virtual vs. physical threads)
    > // and memory resources.
    >
    > Hrm. I know about the memory/cache issues, but it sounds
    > like there's more on the CPU side I don't know much about.
    > Is there more here beyond the memory question and
    > prediction/pipelining?


    With, what is called CMT, we now have the following hierarchy
    of compute resources:
    -> physical CPU
    -> cores
    -> virtual threads
    and the following set (I can't quite call it a hierarchy) of memory
    resources:
    physical RAM attached to a particular CPU's memory controller
    L3/L2 cache
    L1 cache
    These two set of resources can be "attached" to each other in a number
    of different ways (e.g. L1 could be the only per-core cache or L2
    could also be per-core, etc.) and the job of a scheduler is to figure
    out the best mapping of tasks to compute resources based on
    alignment constraints. Paul had a nice post on these constraints
    earlier. Here's an old post from Ingo outlining what is NOT free
    with HyperThreading:
    http://lwn.net/Articles/8553/

    > // Speaking of which -- is SPARC port of Plan9 still alive?
    >
    > Not really. There's a partially-working sparc64 port out there
    > which ran on the Ultra 1 (I think), but it's neither been kept up
    > to date nor made to run on anything beyond that. A few folks
    > (including myself) have poked at it a bit with varying results,
    > none of which were particularly good.
    >
    > Something on Batoka would provide better motivation than my
    > old Ultra 5, though!


    I don't think I can help much with that, but if I ever see a
    homeless Batoka in the hallway it'll be FedExed to you in
    no time ;-)

    Thanks,
    Roman.



  6. Re: [9fans] Plan 9 and multicores/parallelism/concurrency?

    > These two set of resources can be "attached" to each other in a number
    > of different ways (e.g. L1 could be the only per-core cache or L2
    > could also be per-core, etc.) and the job of a scheduler is to figure
    > out the best mapping of tasks to compute resources based on
    > alignment constraints. Paul had a nice post on these constraints
    > earlier. Here's an old post from Ingo outlining what is NOT free
    > with HyperThreading:
    > http://lwn.net/Articles/8553/


    in my performace testing, try and theorize as i might, i have not
    yet been able to see l2 or other cache effects on intel machines.
    i may have seen l1 cache effects, but i rather think the reason
    that pinning the process to a cpu helped was that it was being
    scheduled when it wasn't needed on the other cpu. (that is, the
    design was wrong anway.)

    what i have seen is that the intel 82598 10gbit chip, by keeping
    its tx and rx descriptor rings in cachable regular memory can
    mash the fsb to little bits. it's still pretty fast, though.

    there's no use going fast, if you have no data to go fast on.

    - erik



  7. Re: [9fans] Plan 9 and multicores/parallelism/concurrency?

    On Thu, Jul 17, 2008 at 5:40 AM, erik quanstrom wrote:

    > what i have seen is that the intel 82598 10gbit chip, by keeping
    > its tx and rx descriptor rings in cachable regular memory can
    > mash the fsb to little bits. it's still pretty fast, though.
    >


    it's funny how often this lesson is relearned. But cost is the driver,
    and memory-free NICS are cheaper ... there are even memory-free
    infiniband cards now. But I remember a A Quadrics guy telling me he
    never wanted to put descriptors into main memory ever, ever again.

    ron


+ Reply to Thread