On 16/05/19(Thu) 00:08, Amit Kulkarni wrote: > [...] > > 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.
Why? What's your goal? In other words what kind of scheduling policy you want? When should another thread be selected? What about preemption? > If we go by deadlines, we will not have a way to understand how a proc is > behaving in real time What do you mean by behaving? How much time did it spend running? On which CPU? Can't we monitor that? > 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. So it's because it is simpler? But if we follow this road, not changing anything is also simpler. So why do you want to change the current code? :) > IMHO, a p_deadline field is a better substitute for p_slptime. Why? > 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. Which buglet? Should we fix it? > 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? What do you mean by 'real time tracking field'? I'd suggest you look at how priorities are set when a thread goes to sleep and how they are used when it is awoken.
