On 18.3.2016. 20:00, Mark Kettenis wrote:
> One other important case to test is network packet forwarding. Some
> of our network stack is now running inside a kernel thread. And any
> changes in the scheduling behaviour have the potential of having a
> significant impact there.
I've done some ba
> Date: Sat, 19 Mar 2016 09:06:26 +0100
> From: Alexandre Ratchov
>
> On Fri, Mar 18, 2016 at 08:00:35PM +0100, Mark Kettenis wrote:
> > > From: Bob Beck
> > > Date: Fri, 18 Mar 2016 09:20:35 -0600
> > >
> > > this is cool .. but
> > >
> > > I would be interested in someone comparing server wo
On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek 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 t
Bob Beck wrote:
> this is cool .. but
>
> I would be interested in someone comparing server workloads, as
> opposed to interactive GUI response, using this.
>
> I wouldn't be surprised that inspiriation from BFS would produce
> better interactive response, my bigger concern would be does this
> a
this is cool .. but
I would be interested in someone comparing server workloads, as
opposed to interactive GUI response, using this.
I wouldn't be surprised that inspiriation from BFS would produce
better interactive response, my bigger concern
would be does this adversely impact how we deal with
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 t
Bob Beck [b...@openbsd.org] wrote:
> this is cool .. but
>
> I would be interested in someone comparing server workloads, as
> opposed to interactive GUI response, using this.
>
> I wouldn't be surprised that inspiriation from BFS would produce
> better interactive response, my bigger concern
> w
On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
>
> Please test, and let me know if the performance of something else
> degrades.
>
With your diff firefox consumes twice less cpu (watched the same
video with and without the diff). This suggests firefox spins
somewhere and your d
Edd Barrett wrote:
> On Sat, Mar 19, 2016 at 09:06:26AM +0100, Alexandre Ratchov wrote:
> > The browsers problems seem caused by the way pthreads behave;
> > browsers appear to spin. With the proposed scheduler they spin
> > less. But the real question is why they spin at all?
>
> Inspired by th
Hi Michal,
On Fri Mar 18 2016 10:03, Edd Barrett wrote:
> On Thu, Mar 17, 2016 at 09:26:08PM +0100, Henrik Friedrichsen wrote:
> > On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
> > > Chrome still isn't smooth.
> > >
> > > Please test, and let me know if the performance of someth
Fri, 18 Mar 2016 13:04:49 -0600 Theo de Raadt
> > So I'm skeptical about this BFS scheduler. Don't get me wrong; I do
> > think the scheduler needs attention. But I'm not sure a scheduler
> > designed for interactive desktop use is the best option for OpenBSD.
> > I'm willing to be proven wrong.
> So I'm skeptical about this BFS scheduler. Don't get me wrong; I do
> think the scheduler needs attention. But I'm not sure a scheduler
> designed for interactive desktop use is the best option for OpenBSD.
> I'm willing to be proven wrong. But that means we need careful
> benchmarking on a wi
On Thu, Mar 17, 2016 at 09:26:08PM +0100, Henrik Friedrichsen wrote:
> On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
> > Chrome still isn't smooth.
> >
> > Please test, and let me know if the performance of something else
> > degrades.
>
> While Chrome may not be 100% smooth yet
On Sat, Mar 19, 2016 at 09:06:26AM +0100, Alexandre Ratchov wrote:
> The browsers problems seem caused by the way pthreads behave;
> browsers appear to spin. With the proposed scheduler they spin
> less. But the real question is why they spin at all?
Inspired by this comment, I set out to see if
On 18 March 2016 at 18:02, Michal Mazurek wrote:
> On 09:22:18, 18.03.16, Chris Cappuccio wrote:
>> These are really rough observations. This box spawns lots of dirty
>> perl processes and also lots of fping processes for monitoring.
>
> The next step I had planned was related to juggling processe
On Fri, Mar 18, 2016 at 6:02 PM, Michal Mazurek wrote:
> BFS has one shared queue for all CPUs, maybe there is a very good reason
> for that, we'll see.
Michal,
first of all congrats to optimistic results in interactive workloads.
Honestly I'm a little bit worried about your attempts since I thi
On 09:22:18, 18.03.16, Chris Cappuccio wrote:
> These are really rough observations. This box spawns lots of dirty
> perl processes and also lots of fping processes for monitoring.
The next step I had planned was related to juggling processes between
cpus. Right now that code is untouched, other t
On 18/03/16(Fri) 13:04, Theo de Raadt wrote:
> > So I'm skeptical about this BFS scheduler. Don't get me wrong; I do
> > think the scheduler needs attention. But I'm not sure a scheduler
> > designed for interactive desktop use is the best option for OpenBSD.
> > I'm willing to be proven wrong.
On Fri, Mar 18, 2016 at 08:00:35PM +0100, Mark Kettenis wrote:
> > From: Bob Beck
> > Date: Fri, 18 Mar 2016 09:20:35 -0600
> >
> > this is cool .. but
> >
> > I would be interested in someone comparing server workloads, as
> > opposed to interactive GUI response, using this.
> >
> > I wouldn't
With this diff on my X200, YouTube used to be a stuttering mess on both
chrome and firefox, and is now buttery smooth, even at 1080p. Thanks!
Hey,
On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
> Chrome still isn't smooth.
>
> Please test, and let me know if the performance of something else
> degrades.
While Chrome may not be 100% smooth yet, the system is a lot more
interactive. I can now play YouTube videos without
> From: Bob Beck
> Date: Fri, 18 Mar 2016 09:20:35 -0600
>
> this is cool .. but
>
> I would be interested in someone comparing server workloads, as
> opposed to interactive GUI response, using this.
>
> I wouldn't be surprised that inspiriation from BFS would produce
> better interactive respo
Alexandre Ratchov [a...@caoua.org] wrote:
> On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
> >
> > Please test, and let me know if the performance of something else
> > degrades.
> >
>
> With your diff firefox consumes twice less cpu (watched the same
> video with and without th
On 14:57:40, 15.03.16, Alexandre Ratchov wrote:
> On Sat, Mar 12, 2016 at 05:36:21PM +0100, Michal Mazurek wrote:
> >
> > p_usrpri and p_priority will go away, so userland utilities like 'ps'
> > will need to be changed.
> >
>
> AFAIU, this would hurt interactive programs (audio, players, games,
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
On Sat, Mar 12, 2016 at 05:36:21PM +0100, Michal Mazurek wrote:
>
> p_usrpri and p_priority will go away, so userland utilities like 'ps'
> will need to be changed.
>
AFAIU, this would hurt interactive programs (audio, players, games,
etc). Currently i/o bound processes wake up with increased
p
On 14/03/16(Mon) 16:05, Michal Mazurek wrote:
> On 04:41:05, 13.03.16, Juan Francisco Cantero Hurtado wrote:
> > Here are the commands:
> > ...
> > ffmpeg
> > ...
>
> Thank you for this.
>
> ffmpeg runs differently from gcc or make - it creates a lot of threads.
> I can verify that it is indeed s
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
On 04:41:05, 13.03.16, Juan Francisco Cantero Hurtado wrote:
> Here are the commands:
> ...
> ffmpeg
> ...
Thank you for this.
ffmpeg runs differently from gcc or make - it creates a lot of threads.
I can verify that it is indeed slower. Instead of spending 2 seconds in
'system' it takes 30 or 40
On Sat, Mar 12, 2016 at 10:36 AM, Michal Mazurek
wrote:
> Gregor Best attempted to improve the scheduler in 2011:
> http://comments.gmane.org/gmane.os.openbsd.tech/27059
> Here is another attempt, it takes up where the previous one left off.
>
> This is also mostly based on the main idea behind L
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 t
On Sat, Mar 12, 2016 at 08:35:31PM +0100, Juan Francisco Cantero Hurtado wrote:
> On Sat, Mar 12, 2016 at 05:36:21PM +0100, Michal Mazurek wrote:
> > Gregor Best attempted to improve the scheduler in 2011:
> > http://comments.gmane.org/gmane.os.openbsd.tech/27059
> > Here is another attempt, it tak
On Sat, Mar 12, 2016 at 05:36:21PM +0100, Michal Mazurek wrote:
> Gregor Best attempted to improve the scheduler in 2011:
> http://comments.gmane.org/gmane.os.openbsd.tech/27059
> Here is another attempt, it takes up where the previous one left off.
>
> This is also mostly based on the main idea b
Gregor Best attempted to improve the scheduler in 2011:
http://comments.gmane.org/gmane.os.openbsd.tech/27059
Here is another attempt, it takes up where the previous one left off.
This is also mostly based on the main idea behind Linux CFS or
BFS. I found BFS to be described more clearly:
http://c
34 matches
Mail list logo
