> Why did you decide to change the data structure of the runqueue? What > problem are you trying to solve?
Thanks for your feedback. It forced me to do some introspection. I was trying to explore if we can tweak and make the current code faster, while still tryign to keep it as simple as it is currently. The explanation I gave in the diff for the removal of 32 TAILQs is wrong. That flawed analysis was set in my mind weeks ago, when I was just starting to read the scheduler code. I understand now that the current code is quite a bit better. It places a proc with low value of p_priority in lower array index and will return it first, and a higher value of p_priority will be placed in higher array index. So a proc is being carefully placed in sorted order of p_priority. I will revert this data structure change as the single TAILQ will not return a proc in the sorted p_priority order. > Regarding your work, if you want to continue in the scheduler area, may > I suggest you start by making the global counters per-spc and export > them to userland via a syscl? Add a new view to systat(1) to see what's > happening. Without more visibility it's hard to confirm any theory. This is an excellent idea. It will take me some time to understand the sysctl/systat part and implement, but I will try to address within a week or two. > > Regarding the choice of deriving quantum from the priority, are you sure > the priorities are correct? Should we keep priorities? Or if userland > needs priorities shouldn't we convert quantum into priority and not the > other way around? I am not entirely sure of the p_priority/usrpri/estcpu/load_avg calculations, as I am still trying to make sense of the code. But once we make sure all the p_priority calculations are consistent, I think the priorities are the way to go. If we go by deadlines, we will not have a way to understand how a proc is behaving in real time, as a p_deadline is a history variable, how much a proc used its time slices. But if we stay with priorities, it is way simpler, and ranges strictly from 0 -> 127, and will work with current code. So the code changes will be minimal and easy to understand. Also, UNIX has historically had a concept of priority/nice levels, so I think we should stick with it. IMHO, a p_deadline field is a better substitute for p_slptime. The only reason I added quantum, was that I stumbled on the round robin interval buglet. Initially added a fixed 100 ms per proc, and then decided how much I could explore this quantum idea while still trying to keep the code understandable. I would guess a lot of code in userland is based on priorities, the GNOME/KDE equivalent of top/classical top/htop etc... I would think of p_priority as a real time tracking field of how hot the proc is in using the CPU. In order to change the quantum, how would we decide to increment or decrement it, unless by a real time tracking field? There's code which already does this tracking for p_priority, it might be flawed or complex, so why not fix it and use it? > Regarding your diff, if you find a thread in RUN state inside the sleep > queue (wakeup_n()), something is really wrong there. I added that SRUN assert weeks ago when I was trying to add some code and figure out things, and broke it immediately on boot, the assert made the problem go away, and till your noticing it, I forgot about it. Removed it today and compiled kernel/userland while browsing on a desktop and a kernel build on another dekstop. It worked out fine. Thanks
