On 3/6/25 15:07, ron minnich wrote:
> Jacob re the rebase, thank you, it works in qemu and on my t420.
>
> I'm thinking to just set my 9front head to what you've done, push it to my
> fork, and proceed from there. Do you see any reason not to?
Sure by all means.
>
> Where, ultimately, might we want NIX to land?
>
> I need to start turning the dial down on debug prints, to start.
I think it depends on what the goals are here, I assume you're somewhat
interested in having a conversation about getting
nix in to 9front, so I'll start from there. Here's what I would suggest as the
path forward for that and some followup questions.
1. You'll need to squash your changes in to a smaller organization of patches
that can be reviewed, the current commit list is a bit messy
and does not follow our conventions for commit messages.
2. You'll need to make a case as to what the practical benefits are from having
this capability, it seems like you've gotten somewhere with
the ftq benchmarks, which is great, but you'll need to put things in
terms of practical benefit. What is a program on the system which
would benefit from having a core exclusive to itself? How can we prove
that? Adding stuff to the Proc struct has a high impact and typically
should be accompanied by a decently useful addition.
3. Everything right now is specific to pc64, and I think if this is a general
capability going forward, we're going to need this on the other
architectures that we support. At the very least arm64. I don't know if
I would call this a requirement for getting nix merged but
it should be something that would be a close goal following an initial
merge if not.
4. For now at least, I would suggest removing the debug prints. The question
regarding on how to go forward with debug prints in general is
a good question, and something we can discuss but the discussion of nix
and the discussion on debug prints are two separate discussions
(and ideally two separate patches). To this end I would perhaps be
partial to having some sort of additional file (/dev/kdebug?) that
would serve some ring buffer that can be enabled with a write and would
serve the results. (Think /net/log). This would be a bit more costly
compared to being able to #ifdef them out but I think in this case it
may be worth it.
Once you feel like you've got an organized set of diffs, the code cleaned up,
and some sort of data to make an argument I would say post it over on
the 9front list. Or perhaps pop your head in on irc or one of our jitsi calls
to talk it out in real time.
In general, and in particular with large impact changes like this, expect a lot
of discussion on implementation, organization, and interface for these
patches if you want to go forward with arguing for their inclusion in 9front.
What I tend to do is regularly review the "big diff" against upstream
and check that extra stuff hasn't snuck in.
Stuff like:
https://github.com/majiru/9front/compare/front...nix#diff-3530d7439c30d8e9125572d4c7eb0f42ca56b6adb8b069c7ce08c023c6067e48
https://github.com/majiru/9front/compare/front...nix#diff-4fac6b341748f453f31ecd0d99acc52e6069bef0d85f51200d3a498f31acc9a0R20
https://github.com/majiru/9front/compare/front...nix#diff-4fac6b341748f453f31ecd0d99acc52e6069bef0d85f51200d3a498f31acc9a0R43
You've got some files which are lacking trailing newlines at the very end of
the file as well that you'll want to clean up.
The short of it is now that you've got things to a working state, I'd start
cleaning stuff up, and start asking people to review
these cleaned up version to get feedback on the implementation. If you agree
that this is where you're at with this.
>
> on the original NIX, as we were in an HPC mindset, we made the only TC core
> 0, and all other cores ACs.
>
> I am wondering about a boot-time variable, such that, if not set, there are
> no ACs; and, if set, it means "all cores from this number up" are ACs.
Some sort of plan9.ini setting, maybe just a list of core numbers that you want
to be AC's? I'm thinking something that would allow you to set a specific
list of cores. If for example your intel chip makes every odd numbered chip an
E core, you may want to interleave them.
>
> Also ... re debugging ... do you have some way of controlling, on a fairly
> fine basis, when and how to print debug messages?
I ended up addressing this in the above list.
>
> jmk had done something for 9k, which we also used on blue gene and then NIX,
> not sure when (2005? Charles, do you recall?) that worked like this:
> in, e.g., pc64, you have a dbgflg section. You could define a single letter
> for a subsystem. So, e.g.,
> dbgflg
> acore 'c'
> tcore 'c'
> ioapic 'I'
>
> There was a macro, DBG: DBG(...)
> DBG acts like print if the dbgflg is set FOR THAT FILE.
>
> This all gets munged by awk and friends such that each .c can check
> dbgflg[_DBGC_] to see whether debug prints are enabled. That's all DBG is.
>
> You can make all debugging go away by defining a variable to be 0 and letting
> the linker do the elision (that's one variant of the definition of the
> macros, see
> https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409
> <https://github.com/rminnich/nix-os/blob/regen/sys/src/nix/k10/dat.h#L409>.
> Note a typical jmk comment: horrid :-)
>
> long story short, you could set debug flags in the command line or in
> plan9.ini, and DBG would be enabled or not in the various subsystems. It was
> a very easy way to turn debug on and off on a per-boot-time basis.
>
> It was nice, but it seems to have been lost in most plan 9 kernels.
>
> What do people do now in legacy/9front/whatever?
>
> Finally, for those trying to build NIX, no binds needed. git clone the repo
> of your choice, check out the branch, cd sys/src/9/pc64, and mk.
>
> Finally, ... coders welcome. The level of things to do is WAY less daunting
> now that we are sort of working, and part of the goal of bringing NIX back is
> to suck people in to working on the kernel.
>
> thanks
>
>
> On Wed, Mar 5, 2025 at 1:57 PM <tlaro...@kergis.com
> <mailto:tlaro...@kergis.com>> wrote:
>
> On Wed, Mar 05, 2025 at 09:16:57PM +0100, tlaro...@kergis.com
> <mailto:tlaro...@kergis.com> wrote:
> > On Wed, Mar 05, 2025 at 07:11:02PM +0100, tlaro...@kergis.com
> <mailto:tlaro...@kergis.com> wrote:
> > > I need to update the documentation about the building (one needs to
> > > bind above the 9front hier, but also to get plan9front/firmware, and
> > > to build and install brekky).
> > >
> > > But it also uses ftq.
> >
> > BTW, execac is missing also.
>
> No: here ./sys/src/cmd/execac.c; needs simply to be compiled.
>
> > >
> > > If I'm not mistaken, the git master has an unchanged mkfile relating
> > > to several flavors (ftq{15,31,63}) but is marked as broken.
> > >
> > > Do you compile it under APE?
> > >
> > > On Mon, Mar 03, 2025 at 07:44:47PM -0800, ron minnich wrote:
> > > > I am now able to run the HPC FTQ benchmark and get results, first
> time
> > > > since 2011.
> > > >
> > > > The results are very, very good on my T420. Next step, see how it
> goes on a
> > > > server class machine.
> > > >
> > > > If anyone wants to help out, the rebase would be most welcome, as
> would
> > > > testing of your choice.
> > > >
> > > > Taking a trap on an AC still does not work. I get around that by
> making
> > > > sure traps won't happen but ... would be nice to fix it.
> > > >
> > > > In NIX, we had a new rfork type which would let a process flip
> itself onto
> > > > an AC; it would be useful to bring that over.
> > > >
> > > > Lots to do, whoever wants to help, we're open for business.
> > >
> > > --
> > > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> > > http://www.kergis.com/ <http://www.kergis.com/>
> > > http://kertex.kergis.com/ <http://kertex.kergis.com/>
> > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
> >
> > --
> > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> > http://www.kergis.com/ <http://www.kergis.com/>
> > http://kertex.kergis.com/
> <http://kertex.kergis.com/>
> > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
>
> --
> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> http://www.kergis.com/ <http://www.kergis.com/>
> http://kertex.kergis.com/ <http://kertex.kergis.com/>
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
>
> ------------------------------------------
> 9fans: 9fans
> Permalink:
> https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M39192ec6eef3979dd0ea7579
>
> <https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-M39192ec6eef3979dd0ea7579>
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
> <https://9fans.topicbox.com/groups/9fans/subscription>
>
> *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/Tc82cdeb7e597b9d2-M90f81cabe64c4d4bcdcfd5c7>
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-Mfda66fdb5f902348e2d53be7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
