On Tue, 2020-10-27 at 19:54 +0000, nia wrote: > On Tue, Oct 27, 2020 at 03:14:29PM -0400, David H. Gutteridge wrote: > > On Tue, 27 Oct 2020 at 09:04:28 +0000, nia wrote: > > > On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote: > > > > this doesn't seem like the right design. we have cpus > > > > already that have multiple frequency domains, so this > > > > doesn't work with that setup, so attempt to use it as a > > > > general method for estd etc seems limited and thsu not > > > > the right method. > > > > > > > > eg, rk3399 systems have .cpu0 and .cpu4 domains for the > > > > 4 slow and 2 fast cores it has, and they have both > > > > separate controls as well as list of available freqs: > > > > > > > > machdep.cpufreq.cpu0.target = 1416 > > > > machdep.cpufreq.cpu0.current = 1416 > > > > machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408 > > > > machdep.cpufreq.cpu4.target = 1800 > > > > machdep.cpufreq.cpu4.current = 1800 > > > > machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 > > > > 600 408 > > > > > > > > > > yeah, i'm aware of this, my intent was really only to normalize > > > the variables that didn't have multi-cpu-domain support (since > > > those are already normalized as rk3399) > > > > > > do you think we should use the same variable and tie things to > > > under cpu0 when there isn't support for scaling independent CPUs? > > > > > > > additionally, if we are going to design a "good" API for > > > > this, it should publish things outside of "machdep". > > > > i'd go with hw.cpufreq probbaly. > > > > > > > > (i didn't look, but it sure would be annoying if the old > > > > nodes that have existed for over a decade were changed > > > > and any other 3rd party code or scrip tis now broken.) > > > > > > i actually picked this name because it was already in use and > > > thus already checked by estd. > > > > > > i agree it should go outside machdep, but i didn't want > > > to break existing code. > > > > This has impacted youri@'s NetBSD frequency handling patches in x11/ > > mate-applets, which only make references using > > "machdep.est.frequency" > > at present. > > > > Since this change removes pre-existing sysctl nodes, shouldn't this > > merit a kernel version bump? It potentially breaks things in user- > > space. (I see from the mailing list archives that Mouse asked about > > the idea of retaining old names for compatibility.) > > > > (Now, the mate-applets situation could be improved by the new, > > generic > > means of exposing this information. martin@ had asked for non-x86 > > support in PR pkg/53975, one of the barriers being I imagine few > > people > > have the hardware to test with. I don't.) > > > > Dave > > > > > > i can have a look at mate-applets tomorrow, the current code looks > like it won't work with AMD CPUs on netbsd-9 and that should ideally > be fixed.
Yeah, that's my understanding. (I'm guessing Youri only had Intel hardware to test with, which was also true for me until recently.) > i thought kernel versions were specifically about module > compatibility. That may be the case, that was a question for any kernel developers at large. :) Dave