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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
