sched_ule performance on single CPU

O. Hartmann ohartman at mail.zedat.fu-berlin.de
Tue Apr 15 14:40:22 UTC 2008


Hello,

I experience also a strange lagg when using SCHED_ULE and FreeBSD 7.0 on 
AMD64 platforms with and without UP. I tried to track on FreeBSD 7 from 
the very early days, so I noticed some performance impacts last year 
when something chenged in the scheduling. I'm not very familiar with the 
differences, changes and changes in paradigm when 7.0 was introduced, 
but the experience of massive lagging and slowing down the box when 
either heavy SATA IO and network IO is performed is aware since then.
At this very moment I use a private AMD64 box, a P4 box and a Q6600 
(QuadCore) box, all with very similar kernel configurations, if 
possible. The AMD64 box is based on AMDs single core CPU 3500+ at 2,2 
GHz running a UP (64bit) kernel, the P4 is a SMT capable CPU running a 
SMP kernel (32bit) and so the more modern Q6600 quad core box (64bit). 
All of them running FreeBSD 7.0 with most recent builds.
On the SMP capable boxes I still recognize lagging and getting stuck 
when building world and having also X11 running with some applications 
like Firefox. But due to the performance of the quad core box this isn't 
obvious in most times. On the 32Bit box with hyperthreading I see this 
performance drops/laggs also, but not as massively as I relaize this on 
the potentially faster UP, 64Bit box with UP kernel. On the pure 64bit 
UP box, desktop get stuck for nearly a minute when doing a buildworld 
(make -j2 or make -j1 doesn't matter, make -j4 gets worse). This 
performance impact is also noticable when doing heavy network I/O, the 
throughput does not even drops as expected, it gets stuck and stops 
completely for some seconds.

This behaviour has been discussed on several German mailing lists and it 
seems it is still present.

As far as I can say, with 32bit FreeBSD and with 6.3, all my boxes seem 
to be more responsive as with 7.0, but the overall performance is better 
in 7.0. But I fell really uncomfortable with getting stuck while under 
heavy load.
I will test this weird behaviour next under NFS conditions, using both 
the UP and SMP boxes under heavy load as NFS servers for critical video 
streams of some scientific datasets. If this behaviour is also impacting 
NFS, I will report this here, again. But I guess as the other reports of 
this misbehaviour will vanish in the darkness of the net ...

Regards,
Oliver

Pete French wrote:
>> What I refer is, when quickly open multiple tabs (7 or
>> 8) in firefox and click on the fist tab to type user
>> id while other tabs still downloading, its seems there
>> is a minor yet noticeable delay that I did not
>> experience with sched_4bsd.
>>     
>
> Ah, O.K. - havent noticed that, and it wouldnt bother me
> really. What I found is that if you are doing a 'make buildworld'
> in a window then you can't really use firefox properly
> at all using 4BSD, but you can with ULE. For that I am
> happy to put up with minor delays - overally it's a lot
> more usable.
>
>   
>> To me, its seems there is no noticeable gain with
>> sched_ule, but rather the desktop is bit slow to
>> respond.
>>     
>
> Try the compiling experiment and see if you get the same effect
> as I did. For me it;s a bit win, because I couldnt use the
> desktop when I was compiling code. Swingd and roundabouts
> though - if you dont od big comiles then it may seem theres no
> benifit for you.
>
> -pete.
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>   



More information about the freebsd-stable mailing list