thanks, Jacob. I'm going to keep at it, and your rebase has now made it much easier to keep up.
In the usual manner of such things, I think now that we figured out that we can make it work, it's time to toss a lot of those commits away, and get to something a lot less messy. There's where others can help. ron On Thu, Mar 6, 2025 at 3:38 PM Jacob Moody <mo...@posixcafe.org> wrote: > 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-M4d418c33e9bb34bae86e6ee5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
