On 16:35:49, 13.03.16, Martin Pieuchot wrote: > On 12/03/16(Sat) 17:36, Michal Mazurek wrote: > > [...] > > Some notes: > > > > Chrome is still not very usable. > > Are you wanting to improve the browser experience on OpenBSD? If that's > your goal then I'd suggest you to start by analysing how the browsers > behave. My personal analysis makes me believe that librthread is what > needs some love.
It seems you were right, see my other email. > > p_usrpri and p_priority will go away, so userland utilities like 'ps' > > will need to be changed. > > So what's your plan for process priorities? > ... > "improve performance" does not say much. For which workload on which > machine? There's maybe room for improvement in this area, but you > really need more than "building a kernel" as test bed. Replace them with "deadlines", to achieve "fair" scheduling. This should provide superior scheduling for interactive applications. We'll see :) > > - if (--ci->ci_schedstate.spc_rrticks <= 0) > > + if (p && (--(p->p_rrticks) <= 0)) > > roundrobin(ci); > > That's an interesting change. Why did you decide to move a per-CPU > counter to a per-process one? Can you explain the effect it will have? > Or even better can you measure its effect on different workloads? That's the supposedly genious idea behind BFS. An interactive process can yield, and let batch processes do their work. Then when it's time to process cursor movement, it will come back with the best priority, but with used up p_rrticks to prevent abuse. We'll see... Perhaps it should be operated on as an element of the ci_schedstate structure, similar to how spc_curpriority is a copy of p_piority now, and copied to/from proc during context switches? I don't know yet. > > - SCHED_ASSERT_LOCKED(); > > + nanouptime(&now); > > + niffies = now.tv_sec * (1000 * 1000 * 1000) + now.tv_nsec; > > Can you explain how you chose this period of time and what it is > supposed to represent? These are niffies, like jiffies but nanoseconds. A high precision monotinically increasing counter. The value itself isn't really important. Some multipliers for 'nice' offsets will need to be chosen though. > > @@ -509,56 +457,8 @@ setrunnable(struct proc *p) > > p->p_stat = SRUN; > > p->p_cpu = sched_choosecpu(p); > > setrunqueue(p); > > - if (p->p_slptime > 1) > > - updatepri(p); > > What's happening to p_slptime? It's not needed for the new scheduler. The 4BSD scheduler does stuff to the priorities based on how many seconds a process has been sleeping. -- Michal Mazurek
