On Thu, 16 May 2019 15:15:24 -0300 Martin Pieuchot <m...@openbsd.org> wrote:
> 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. Hi Martin, I feel that you are trying to point out something by giving me some hints. Please give me some time to think through all possible scenarios, and I will send a detailed reply to all the points you raised above in this email, with a reduced+functional diff, over this weekend. @Solene, thanks for testing, please ignore the previous diff for now. Thanks
