Two questions I am wondering about:

1. Is this still limited to x86 only, as I think was suggested on an earlier thread related to this effort, or has it been generalized to work across other CPU architectures?

2. As this evidently needs to be "enabled" by configuring processors to act as ACs, once generalized across architectures to whatever extent is possible and tested as stable, would there be any reason not to roll this into 9front itself rather than keeping it as a separate project?


On 2/9/25 02:07, ron minnich wrote:
NIX this evening. Test on 4 core laptop.

fshalt -r does not end well on my laptop; it's the usual issue with drivers not dealing that well with a warm reset, and hardware being hard.

So: I modified bootrc to drop me into rc before it starts mounting file systems and such. I added execac to the image. fshalt -r 9pc64 and I can run execac as a test.

And it works on my T420 :-)

So, next step: try the fixed time quantum (FTQ) benchmark: github.com/rminnich/ftq <http://github.com/rminnich/ftq> and compare noise results from a TC and an AC.

ftq measures interference that can cause scaling issues in supercomputers, more here: https://www.researchgate.net/publication/4123211_Analysis_of_microbenchmarks_for_performance_tuning_of_clusters

We developed FTQ at LANL to measure noise. Some results here: https://docs.google.com/presentation/d/1_BsQaO_0hdz8RSW1PAzMH6rVDQmdkwupfTmr-x5EXq4/edit?usp=sharing

In 2003 we got far better FTQ results on Plan 9 than on linux, which is why in 2003 I started the Plan 9 for supercomputing project. We got really good results on Blue Gene in 2007.

in 2011, I got the best results ever measured, and still the best on just about everything I've ever seen in 25 years, using NIX on an AC. These would have been great results on machine in single user mode, but they were achieved on a fully booted machine running rio -- since the AC was left alone to do its thing.

Here's hoping that still holds; I'll try it tomorrow. Will be pretty nice to see if it works out.

But ... NIX is ready enough for you to try. I have no idea if it's any use for anyone, but thanks to Paul for getting this port off the ground, and Thierry, who kicked it into gear by asking the right question at the right time.

github.com/rminnich/9front <http://github.com/rminnich/9front>, 9front branch

On Sat, Feb 8, 2025 at 9:16 AM Paul Lalonde <paul.a.lalo...@gmail.com> wrote:

    Nice!  Congratulations!



    On Sat, Feb 8, 2025, 9:13 a.m. ron minnich <rminn...@gmail.com> wrote:

        ok that's fixed and:

        % ratrace -c execac -c 1 /bin/date
        98 execac Running 204326 0x1prepage: base 0x7ffffefff000 top
        0x7ffffffff000
        prepage: base 0x200000 top 0x400000
        prepage: base 0x400000 top 0x406000
        prepage: base 0x406000 top 0x406000
        /bin/date: timezone: file does not exist: '/env/timezone'
         = process exited
        % k

        I *think* that means it worked.

        First execac I've run in ... well ... a long time.

        On Sat, Feb 8, 2025 at 8:17 AM ron minnich
        <rminn...@gmail.com> wrote:

            The new default branch is 9front.
            https://github.com/rminnich/9front

            I just pushed a commit that:
            1. has the execac command use sysr1 for now
            2. drops bootrc into a shell before root is mounted so you
            can poke around and run execac
            3. adds ratrace, execac, and date

            When you build nix, look in systab.h, replace
            [SYSR1] sysr1,
            with
            [SYSR1] sysexecac

            it's just easier to coopt sysr1 for now

            when you boot, make sure you have at least 2 cores; when
            it drops to a shell, try this
            execac -c 1 /bin/date
            That would run /bin/date on core 1.

            In a perfect world.

            well ...
            qunlock called with qlock not held, from 0xffffffff8021e5c2
            qunlock called with qlock not held, from 0xffffffff8021e5c2

            oops.

            If you know how to debug qemu with gdb, well, here's a
            place to start.
            Or just look at what's at that PC in the kernel, and see
            what it might be



*9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions <https://9fans.topicbox.com/groups/9fans> + participants <https://9fans.topicbox.com/groups/9fans/members> + delivery options <https://9fans.topicbox.com/groups/9fans/subscription> Permalink <https://9fans.topicbox.com/groups/9fans/T5032253608c13e6b-Mc2f9940ca91aa8c661eb2591>
------------------------------------------
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc4be07fc1c6ad31c-M554dde1d1703d80e2afe9d53
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Reply via email to