Forgive the layman question but is NIX somewhat similar to cgroups in the Linux kernel?
On Fri, Mar 7, 2025, 6:08 AM <tlaro...@kergis.com> wrote: > On Thu, Mar 06, 2025 at 03:47:42PM -0800, ron minnich wrote: > > 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. > > > > May I ask why you didn't keep the small nix set of files that you (I > mean you Ron, and Paul) have finally selected? > > It seems to me that having, a la 9legacy (that has sys/src/9 and > sys/src/9k), a sys/src/nix, that is having a git repo just nix, with a > branch 9front (this flavor has just to be binded in 9front > sys/src/nix) and, why not, a 9legacy (this flavor has just to binded > in 9legacy sys/src/nix) would avoid the pain, for now, to have to > update when 9front is moving and will have the supplementary benefit > of showing what is Nix. > > IMHO, it seems it will be far more easier for people wanting to > contribute to have just the Nix set of added or modified files in one > directory and to let you and others joining focus on Nix related > things without to have to bother merging or cherry picking > "surroundings". > > Also a nix/nix for scaffolding scripts (building a namespace---in the > case of a dedicated nix/ dir---, testing and so on). > > FWIW. > > T. Laronde > > > 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 > > -- > Thierry Laronde <tlaronde +AT+ kergis +dot+ com> > http://www.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-M3acd2f3951c9034f283b33b1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
