Date: Tue, 15 Apr 2008 16:24:11 +0200 From: "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de> To: Pete French <petefrench@ticketswitch.com> Cc: unga888@yahoo.com, freebsd-stable@freebsd.org Subject: Re: sched_ule performance on single CPU Message-ID: <4804BA8B.1020905@mail.zedat.fu-berlin.de> In-Reply-To: <E1JkI7L-000GIu-QH@dilbert.ticketswitch.com> References: <E1JkI7L-000GIu-QH@dilbert.ticketswitch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 "freebsd-stable-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4804BA8B.1020905>