It's not like cgroups at all. Consider a system with lots of CPUs. Kernels, as they boot, will allocate all those CPUs for their own use. These CPUs will assigned to different processes over time, or be assigned to running kernel processes. Interrupts will be scheduled across this set of cores, with one goal being to distribute them in some sort of fair fashion.
These are time sharing cores (TC). NIX adds a new class of cores, called Application cores. An Application core does not get involved in any of this activity. Instead, they wait to be assigned work to do. Once assigned that work, they run it until the work exits. The work will not be interrupted; indeed, interrupts are disabled. The ACs run a very small for loop which waits on work to do and does it. It's very, very different from cgroups, which are really just resource consumption definitions. thanks On Fri, Mar 7, 2025 at 12:25 PM Clout Tolstoy <tolstoycl...@gmail.com> wrote: > 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 <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-M3acd2f3951c9034f283b33b1> > > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc82cdeb7e597b9d2-Meaff60439e36e8e26e963ce2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
