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