Michal Mazurek [akf...@jasminek.net] wrote: > On 16:28:33, 14.03.16, Martin Pieuchot wrote: > > > The number of calls to yield() dropped to 4,576. > > > > This is really similar to what I observed with Firefox and Chrome. > > > > > This is where I get stuck, I don't know how to replace the call to > > > sched_yield(), or whether it is a good idea to do so. Any advice? > > > > I'd assume the problem is not in the _spinlock() implementation itself > > but rather on the code calling this lock. Do you know which code is > > triggering this? > > > > See r1.13 of lib/librthread/rthread_libc.c, this is an example where a > > the use of a spinlock created similar symptoms. > > I don't know how to fix it, but in the meanwhile here is a workaround so > I can continue working on the scheduler. In yield(): > > + tmp = p->p_rrticks; > + sched_deadline(p); > + p->p_rrticks = tmp; > > So penalise a process calling yield() by giving it the worst deadline, > i.e. make it go to the end of the run queue. > > Other than this, no changes. > > Chrome still isn't smooth. >
On a frankenstein 5.9 kernel with bob beck's latest NOWAIT vfs_biomem buffer alloc and this, I'm getting very smooth action on chrome, with video, even on an old x201. I don't remember the last time it could re-open 20 tabs without constantly pausing most of itself, or the last time youtube videos would play on this laptop in chrome, without random and frequenty stuttering.
