Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Steven Hartland wrote: > With the patch things are MUCH better. No problems to report and > the server is under major load including some heavy disk access as Yeah, no problems here either, so far. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
- Original Message - From: "Kris Kennaway" <[EMAIL PROTECTED]> Jeff said he'll merge it in a week or two after it's been well-tested. Been running it here on our ftp which was getting major issues with disk access spiking "system" usage to 90+% making the server totally unresponsive for 5 - 10 seconds at a time. With the patch things are MUCH better. No problems to report and the server is under major load including some heavy disk access as I clean up some dirs with 1.4 million files in a single dir /me slaps users :p Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.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]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Sat, Jun 11, 2005 at 09:52:13PM +0200, Matthias Buelow wrote: > I wrote: > > Kris Kennaway wrote: > >> http://www.chesapeake.net/~jroberson/flushbuf.diff > >>Does it work for you on 5.4? > > The patch seems to work. Cool, that makes a difference like between > > BTW., is that change being included in 5-STABLE or just for 6-CURRENT? > > mkb. > Jeff said he'll merge it in a week or two after it's been well-tested. Kris pgpkOYLjgWhdk.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
I wrote: > Kris Kennaway wrote: >> http://www.chesapeake.net/~jroberson/flushbuf.diff >>Does it work for you on 5.4? > The patch seems to work. Cool, that makes a difference like between BTW., is that change being included in 5-STABLE or just for 6-CURRENT? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: > http://www.chesapeake.net/~jroberson/flushbuf.diff > Does it work for you on 5.4? The patch seems to work. Cool, that makes a difference like between night and day. I can't determine any observable effect of untarring the firefox source anymore to interactive response time (when it's non-disk bound, of course), where before applying the patch, the mouse cursor would jump, audio stutter and I could barely type in xterms. Seems to work perfectly again. Thanks! mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Thu, May 26, 2005 at 02:15:54AM +0200, Matthias Buelow wrote: > > >>Others don't see this though, and in other cases it was *definitively > >>proven* to be caused by the issue I mentioned. I'll have to think > >>more about what to try next..thanks for running the tests. > > > >Perhaps it's something SATA-related? > > Before restoring my 5.4 dumps after testing -current, I installed > fedora3 linux just to verify it isn't somehow the hardware itself. Ok, > plain installation from CDs, kernel "2.6.9-1.667smp" (default > installation kernel). There was absolutely zero noticable lag or any > effect on response time on X11 while untarring the same firefox source. > So there really seems to be something foul in FreeBSD in that regard. > And now for the dumps.. *sigh*. In case you didn't see it, Jeff identified the probable cause of this and developed the followng patch: http://www.chesapeake.net/~jroberson/flushbuf.diff Does it work for you on 5.4? Kris pgplKQmUvEU5U.pgp Description: PGP signature
Re: Lifetime of FreeBSD branches
Scott Long wrote: Yeah, and what I'm trying to do is smooth the bumps for the long term. The 4.x->5.x transition was simply a gigantic mess for users, and it was largely a function of it being 4+ years in the making. It still _is_ a gigantic mess. My hosted 5.3-stable server just crapped itself for the second time this year, for no apparent reason. I suggest reestablishing 4.x as the "production" tree and continuing to maintain it for a while, including making releases, and regressing 5.x to what it is and probably will be for quite a while: "experimental". mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
On Friday 27 May 2005 23:22, Matthias Buelow wrote: > Scott Long wrote: > > Yeah, and what I'm trying to do is smooth the bumps for the long > > term. The 4.x->5.x transition was simply a gigantic mess for users, > > and it was largely a function of it being 4+ years in the making. > > It still _is_ a gigantic mess. My hosted 5.3-stable server > just crapped itself for the second time this year, for no apparent > reason. I suggest reestablishing 4.x as the "production" tree and > continuing to maintain it for a while, including making releases, and > regressing 5.x to what it is and probably will be for quite a while: > "experimental". And to counter your rant, I've been using 5.x since 5.0-DP1 on a range of hardware (mostly i386 in quite different setups, and more recently amd64 too) with virtually no problems. On the other hand, 4.x (I think it was 4.9, but I really cannot remember for sure) crapped all over one box so hard I refuse to ever use it again. A. -- Andy Fawcett | [EMAIL PROTECTED] | [EMAIL PROTECTED] "In an open world without walls and fences, | [EMAIL PROTECTED] we wouldn't need Windows and Gates." -- anon | [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On 5/26/05, Matthias Buelow <[EMAIL PROTECTED]> wrote: > > >> Others don't see this though, and in other cases it was *definitively > >> proven* to be caused by the issue I mentioned. I'll have to think > >> more about what to try next..thanks for running the tests. > > > > Perhaps it's something SATA-related? > > Before restoring my 5.4 dumps after testing -current, I installed > fedora3 linux just to verify it isn't somehow the hardware itself. Ok, > plain installation from CDs, kernel "2.6.9-1.667smp" (default > installation kernel). There was absolutely zero noticable lag or any > effect on response time on X11 while untarring the same firefox source. > So there really seems to be something foul in FreeBSD in that regard. > And now for the dumps.. *sigh*. I have the same problem (and have had it for a long time) on both my dual Xeon 550MHz and Athlon XP 2000+ machines. I'm running 6-CURRENT (perhaps this thread should move to the -CURRENT list). I'm working on the dual Xeon right now, so here are some data points from that machine: - I only see it when there is heavy file activity, for example untarring firefox or untarring X. Probably because these have a lot of small files. - I do not see it when compiling world or doing other compiles - I don't have any shared irqs. - I don't have an excessive amount of interrupts, not on the USB irq nor on any other irq channels. I think I remember someone (Scott? Jeff? Don Lewis?) mentioning the problem on another mailing list, and noting that it is a problem with the filesystem that is difficult to fix. I'll try to find that post. Arjan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
Scott Long wrote: No, 4.x is stale enough. If you need help debugging your computer, please let me know and I will personally fix it for you. Sorry for letting some steam out.. I guess I shouldn't answer directly after a crash. Frankly, I don't know what caused it, so just ignore my rant. I cannot provide details since I've got neither a crashdump now (will fix that for next time), nor access to the console. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
Matthias Buelow wrote: Scott Long wrote: Yeah, and what I'm trying to do is smooth the bumps for the long term. The 4.x->5.x transition was simply a gigantic mess for users, and it was largely a function of it being 4+ years in the making. It still _is_ a gigantic mess. My hosted 5.3-stable server just crapped itself for the second time this year, for no apparent reason. I suggest reestablishing 4.x as the "production" tree and continuing to maintain it for a while, including making releases, and regressing 5.x to what it is and probably will be for quite a while: "experimental". mkb. No, 4.x is stale enough. If you need help debugging your computer, please let me know and I will personally fix it for you. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
Francisco Reyes wrote: On Thu, 26 May 2005, Scott Long wrote: Is the goal to have a new major branch every 2 years? Yes. This will allow us to pace our major development projects much better than we have in the past. Someone mentioned 5.X will be supported till 2007 (or at least that's the plan). So will, in average, branches be supported 2 years after a new one takes over? Yes, that is the usual policy of the security team. There will likely be other developers that push changes into the 5.x stream for some time to come. Sounds like a good strategy for most shops. I can imagine that for a big shop with lots of machines it may be a bit agressive, but I am not one of them. :-).. besides big shops likely have developed entire systems around how to deploy the OS to many machines. Yeah, and what I'm trying to do is smooth the bumps for the long term. The 4.x->5.x transition was simply a gigantic mess for users, and it was largely a function of it being 4+ years in the making. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
On Thu, 26 May 2005, Scott Long wrote: Is the goal to have a new major branch every 2 years? Yes. This will allow us to pace our major development projects much better than we have in the past. Someone mentioned 5.X will be supported till 2007 (or at least that's the plan). So will, in average, branches be supported 2 years after a new one takes over? Sounds like a good strategy for most shops. I can imagine that for a big shop with lots of machines it may be a bit agressive, but I am not one of them. :-).. besides big shops likely have developed entire systems around how to deploy the OS to many machines. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
Francisco Reyes wrote: > So why have a 6.X naming convention to begin with? > Why not just stay in 5.X name wise? Because 5.x has been declared to be STABLE, and some of the changes in 6.x will require that applications (and especially kernel modules) be recompiled (which isn't allowed on a stable branch). > Is the goal to have a new major branch every 2 years? Something like that, yes. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
Francisco Reyes wrote: On Tue, 24 May 2005, Scott Long wrote: Again, please don't take the abrupt switch to 6.0 to mean that 5.x is flawed or that 6.x will also have a short lifespan. The real purpose of the switch is nothing but positive; it'll keep us focused and prevent us from overreaching and overextending ourselves. It's a very good and very postive strategy. So why have a 6.X naming convention to begin with? Why not just stay in 5.X name wise? I really should have given 5.3 the name of 6.0. I considered it at the time, but decided not to for some insane reason. Is there a thread that sheds some light on that topic? Is the goal to have a new major branch every 2 years? Yes. This will allow us to pace our major development projects much better than we have in the past. Thus, a ".0" release becomes less of a major event with lofty goals, and more of a snapshot of where our technology is at the time. There will still be goals and major projects, but I don't want us to go through another exercise of spending 4+ years on loosely defined goals that grow out of bounds. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
On Tue, 24 May 2005, Scott Long wrote: Again, please don't take the abrupt switch to 6.0 to mean that 5.x is flawed or that 6.x will also have a short lifespan. The real purpose of the switch is nothing but positive; it'll keep us focused and prevent us from overreaching and overextending ourselves. It's a very good and very postive strategy. So why have a 6.X naming convention to begin with? Why not just stay in 5.X name wise? Is there a thread that sheds some light on that topic? Is the goal to have a new major branch every 2 years? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Others don't see this though, and in other cases it was *definitively proven* to be caused by the issue I mentioned. I'll have to think more about what to try next..thanks for running the tests. Perhaps it's something SATA-related? Before restoring my 5.4 dumps after testing -current, I installed fedora3 linux just to verify it isn't somehow the hardware itself. Ok, plain installation from CDs, kernel "2.6.9-1.667smp" (default installation kernel). There was absolutely zero noticable lag or any effect on response time on X11 while untarring the same firefox source. So there really seems to be something foul in FreeBSD in that regard. And now for the dumps.. *sigh*. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 04:02:58PM -0700, Jon Dama wrote: > It's different, yes. But the trouble is that you need a controlled > interrupt source--i.e., you have to have some concept of when an "event" > might have been handled (were it not for such and such activity). > > I posit that without that counterfactual talking about PREEMPTION is > meaningless. > > The technique I mentioned--measuring and comparing the jitter was intended > to quash measuring the performance of the network stack itself. > > Do you have an idea how you can pose that counterfactual in a synthetic > arrangement more closely connected with the problem at hand? Nope..that's why I said it was a hard thing to study. Well-controlled benchmarking of FreeBSD is always welcome, so please feel free to proceed with your tests and let us know of anything interesting you identify. Kris pgpN9gRvgk7Mp.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
It's different, yes. But the trouble is that you need a controlled interrupt source--i.e., you have to have some concept of when an "event" might have been handled (were it not for such and such activity). I posit that without that counterfactual talking about PREEMPTION is meaningless. The technique I mentioned--measuring and comparing the jitter was intended to quash measuring the performance of the network stack itself. Do you have an idea how you can pose that counterfactual in a synthetic arrangement more closely connected with the problem at hand? ... -Jon On Wed, 25 May 2005, Kris Kennaway wrote: > On Wed, May 25, 2005 at 03:33:39PM -0700, Jon Dama wrote: > > Could this be quantified by setting up a synthetic experiement: > > > > 1) one machine uses dummynet to generate a uniform packet/sec stream > > 2) another machine has a process receiving those packets and recording > >their arrival relative to the local TSC. afaik, the TSC is the only > >source of wall-time that doesn't involve a system call. Is that right? > >Are the TSCs synchronized on SMP systems? > > 3) Generate another source of activity on the receiving machine to > >estimate the effect of PREEMPTION relative to the (lack of) quiescence. > > 4) use the jitter in the TSC deltas to infer the effect of preemption > > That would be attempting to benchmark something entirely different. > > Kris > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 03:33:39PM -0700, Jon Dama wrote: > Could this be quantified by setting up a synthetic experiement: > > 1) one machine uses dummynet to generate a uniform packet/sec stream > 2) another machine has a process receiving those packets and recording >their arrival relative to the local TSC. afaik, the TSC is the only >source of wall-time that doesn't involve a system call. Is that right? >Are the TSCs synchronized on SMP systems? > 3) Generate another source of activity on the receiving machine to >estimate the effect of PREEMPTION relative to the (lack of) quiescence. > 4) use the jitter in the TSC deltas to infer the effect of preemption That would be attempting to benchmark something entirely different. Kris pgpJra1DkqzD7.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Could this be quantified by setting up a synthetic experiement: 1) one machine uses dummynet to generate a uniform packet/sec stream 2) another machine has a process receiving those packets and recording their arrival relative to the local TSC. afaik, the TSC is the only source of wall-time that doesn't involve a system call. Is that right? Are the TSCs synchronized on SMP systems? 3) Generate another source of activity on the receiving machine to estimate the effect of PREEMPTION relative to the (lack of) quiescence. 4) use the jitter in the TSC deltas to infer the effect of preemption -Jon On Thu, 26 May 2005, Bjarne Wichmann Petersen wrote: > On Wednesday 25 May 2005 23:45, Kris Kennaway wrote: > > On Wed, May 25, 2005 at 11:42:01PM +0200, Bjarne Wichmann Petersen wrote: > > > I've had PREEMTION enabled in 5-STABLE for at couple of month and had the > > > opposite experience. Eg. when clicking on a file in a fileselector (I'm > > > using KDE) it would take 2-3 seconds before the file got highlighted. > > > After disabling PREEMTION again responsetime seems to have improved. > > Are you running 5.4-RELEASE or later? > > Later (5.4-STABLE). > > Hmm... did a little testing. Sometimes I *still* get "long" responsetimes with > PREEMPTION disabled in a seemingly random order. > > Bjarne > ___ > 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]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Thu, May 26, 2005 at 12:14:35AM +0200, Bjarne Wichmann Petersen wrote: > On Wednesday 25 May 2005 23:45, Kris Kennaway wrote: > > On Wed, May 25, 2005 at 11:42:01PM +0200, Bjarne Wichmann Petersen wrote: > > > I've had PREEMTION enabled in 5-STABLE for at couple of month and had the > > > opposite experience. Eg. when clicking on a file in a fileselector (I'm > > > using KDE) it would take 2-3 seconds before the file got highlighted. > > > After disabling PREEMTION again responsetime seems to have improved. > > Are you running 5.4-RELEASE or later? > > Later (5.4-STABLE). > > Hmm... did a little testing. Sometimes I *still* get "long" responsetimes > with > PREEMPTION disabled in a seemingly random order. This kind of thing is very difficult to diagnose..your system might be busy doing something else, KDE could be at fault, KDE could be swapped out, etc. Kris pgpad5ZTCUnoA.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wednesday 25 May 2005 23:45, Kris Kennaway wrote: > On Wed, May 25, 2005 at 11:42:01PM +0200, Bjarne Wichmann Petersen wrote: > > I've had PREEMTION enabled in 5-STABLE for at couple of month and had the > > opposite experience. Eg. when clicking on a file in a fileselector (I'm > > using KDE) it would take 2-3 seconds before the file got highlighted. > > After disabling PREEMTION again responsetime seems to have improved. > Are you running 5.4-RELEASE or later? Later (5.4-STABLE). Hmm... did a little testing. Sometimes I *still* get "long" responsetimes with PREEMPTION disabled in a seemingly random order. Bjarne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 11:42:01PM +0200, Bjarne Wichmann Petersen wrote: > On Monday 23 May 2005 23:36, Kris Kennaway wrote: > > > Also try defining PREEMPTION in your kernel on 5.x and above (if you > > are running i386 or amd64). There have been very occasional reports > > of panics with this option enabled (although I use it everywhere and > > have not seen problems on my heavily loaded machines), but interactive > > response should be much better. > > I've had PREEMTION enabled in 5-STABLE for at couple of month and had the > opposite experience. Eg. when clicking on a file in a fileselector (I'm using > KDE) it would take 2-3 seconds before the file got highlighted. After > disabling PREEMTION again responsetime seems to have improved. Are you running 5.4-RELEASE or later? Kris pgpxUT9HdCRJe.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Monday 23 May 2005 23:36, Kris Kennaway wrote: > Also try defining PREEMPTION in your kernel on 5.x and above (if you > are running i386 or amd64). There have been very occasional reports > of panics with this option enabled (although I use it everywhere and > have not seen problems on my heavily loaded machines), but interactive > response should be much better. I've had PREEMTION enabled in 5-STABLE for at couple of month and had the opposite experience. Eg. when clicking on a file in a fileselector (I'm using KDE) it would take 2-3 seconds before the file got highlighted. After disabling PREEMTION again responsetime seems to have improved. Bjarne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: Others don't see this though, and in other cases it was *definitively proven* to be caused by the issue I mentioned. I'll have to think more about what to try next..thanks for running the tests. Perhaps it's something SATA-related? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 06:44:37PM +0200, Matthias Buelow wrote: > Kris Kennaway wrote: > > >>interrupt total rate > >>irq1: atkbd0 586 0 > >>irq13: npx01 0 > >>irq14: ata0 94 0 > >>irq17: wi054 0 > >>irq20: fxp0 atapci162079 99 > >>irq21: uhci0 ehci0 1 0 > >>irq22: uhci11102 1 > >>lapic0: timer1246549 1994 > >>lapic1: timer1246427 1994 > >>Total2556893 4091 > >>The only relevant conflict I could see is irc 20; but I had already > >>tested that by removing fxp0 from the kernel. > > > >I wonder if USB is causing the problem all on its own..since that was > >the culprit in other situations when it was being triggered by virtue > >of interrupt sharing. Any chance you can try a non-USB mouse and > >remove USB from your kernel? > > Ok, now USB (both uhci and ehci) is gone. The problem is still the > same. vmstat -i: > > interrupt total rate > irq1: atkbd01324 3 > irq12: psm0 8562 21 > irq13: npx01 0 > irq14: ata0 94 0 > irq17: wi0 381 0 > irq20: fxp0 atapci161956154 > lapic0: timer 801433 1993 > lapic1: timer 801292 1993 > Total1675043 4166 > > To be frank, I do not believe it's got anything to do with locking or > interrupts. It somehow seems just like the scheduler is doing a bad job > of balancing interactive processes vs. disk i/o. I've seen the same > stuff for years on NetBSD (until they changed scheduling around 1.5 or > so) and Linux (until 2.4 kernels). During that time FreeBSD didn't > exhibit these symptoms and only in 5.x have I seen that kind of > behaviour creep back in. Has the classic scheduler been changed > somehow? Maybe I should try and see if the problem persists with the > ULE scheduler? Others don't see this though, and in other cases it was *definitively proven* to be caused by the issue I mentioned. I'll have to think more about what to try next..thanks for running the tests. Kris pgpWStVHX8C2v.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
somehow? Maybe I should try and see if the problem persists with the ULE scheduler? No difference with ULE, with the default parameters: kern.sched.name: ule kern.sched.slice_min: 10 kern.sched.slice_max: 142 kern.sched.preemption: 1 mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: interrupt total rate irq1: atkbd0 586 0 irq13: npx01 0 irq14: ata0 94 0 irq17: wi054 0 irq20: fxp0 atapci162079 99 irq21: uhci0 ehci0 1 0 irq22: uhci11102 1 lapic0: timer1246549 1994 lapic1: timer1246427 1994 Total2556893 4091 The only relevant conflict I could see is irc 20; but I had already tested that by removing fxp0 from the kernel. I wonder if USB is causing the problem all on its own..since that was the culprit in other situations when it was being triggered by virtue of interrupt sharing. Any chance you can try a non-USB mouse and remove USB from your kernel? Ok, now USB (both uhci and ehci) is gone. The problem is still the same. vmstat -i: interrupt total rate irq1: atkbd01324 3 irq12: psm0 8562 21 irq13: npx01 0 irq14: ata0 94 0 irq17: wi0 381 0 irq20: fxp0 atapci161956154 lapic0: timer 801433 1993 lapic1: timer 801292 1993 Total1675043 4166 To be frank, I do not believe it's got anything to do with locking or interrupts. It somehow seems just like the scheduler is doing a bad job of balancing interactive processes vs. disk i/o. I've seen the same stuff for years on NetBSD (until they changed scheduling around 1.5 or so) and Linux (until 2.4 kernels). During that time FreeBSD didn't exhibit these symptoms and only in 5.x have I seen that kind of behaviour creep back in. Has the classic scheduler been changed somehow? Maybe I should try and see if the problem persists with the ULE scheduler? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Krzysztof Kowalik [EMAIL PROTECTED] wrote: > [...] > cvsup-ing current 6.0-CURRENT right now, to check the giantless VFS once > again. It will probably take an hour to get it up and running. Unfortunately, 6.0-CURRENT didn't help at all. FreeBSD 6.0-CURRENT #0: Wed May 25 13:24:30 CEST 2005 [...] Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP 2000+ (1668.71-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc040 real memory = 1073725440 (1023 MB) avail memory = 1041891328 (993 MB) ACPI APIC Table: [...] pcm0: port 0xd800-0xd8ff at device 5.0 on pci0 [...] atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 [...] atapci0: port 0xd400-0xd407,0xd000-0xd003,0xb800-0xb807,0xb400-0xb403,0xb000-0xb00f mem 0xe580-0xe5803fff irq 19 at device 6.0 on pci0 ata2: on atapci0 ata3: on atapci0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x9800-0x980f at device 17.1 on pci0 ata0: on atapci1 ata1: on atapci1 [...] ad0: 38166MB at ata0-master UDMA100 [...] # vmstat -i interrupt total rate irq1: atkbd0 704 2 irq3: sio1 1 0 irq4: sio0 1 0 irq6: fdc010 0 irq12: psm0 7143 24 irq13: npx01 0 irq14: ata046427160 irq15: ata1 67 0 irq16: fxp0 284 0 irq17: pcm0 4414 15 lapic0: timer 575578 1991 Total 634630 2195 # sysctl -a|grep mpsafe debug.mpsafevfs: 1 debug.mpsafenet: 1 debug.mpsafevm: 1 The issues still exist. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Krzysztof Kowalik [EMAIL PROTECTED] wrote: > [...] > I will try to put my hands on the mentioned AMD box once again, to run > some current 6.0 on it. OK, got the box. I ran a 5.4-RELEASE, identical (as I just restored dumps of my current workstation on it) as the one not giving problems on Intel-based system. Regardless of the state of USB, I can observe the mentioned issues (scattered sound, lagging mouse in X, etc while untarring firefox's sources). With USB, vmstat -i shows: interrupt total rate irq1: atkbd0 904 2 irq3: sio1 1 0 irq4: sio0 1 0 irq6: fdc010 0 irq8: rtc 56478127 irq12: psm0 4912 11 irq13: npx01 0 irq14: ata0 8529 19 irq15: ata1 63 0 irq16: fxp0 uhci1 437384987 irq17: pcm0 1576 3 irq0: clk 441323996 Total 951182 2147 ... and without it: interrupt total rate irq1: atkbd0 164 1 irq3: sio1 1 0 irq4: sio0 1 0 irq6: fdc010 0 irq8: rtc 19340127 irq12: psm0 7005 46 irq13: npx01 0 irq14: ata018731123 irq15: ata1 61 0 irq16: fxp0 132 0 irq17: pcm0 2448 16 irq0: clk 151117994 Total 199011 1309 cvsup-ing current 6.0-CURRENT right now, to check the giantless VFS once again. It will probably take an hour to get it up and running. If you have any more ideas, while I still have the box, I'd be willing to try, time permitting. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: I wonder if USB is causing the problem all on its own..since that was the culprit in other situations when it was being triggered by virtue of interrupt sharing. Any chance you can try a non-USB mouse and remove USB from your kernel? Yes, I'll try that later. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 07:26:31AM +0200, Matthias Buelow wrote: > Kris Kennaway wrote: > > >Show me vmstat -i now. > > interrupt total rate > irq1: atkbd0 586 0 > irq13: npx01 0 > irq14: ata0 94 0 > irq17: wi054 0 > irq20: fxp0 atapci162079 99 > irq21: uhci0 ehci0 1 0 > irq22: uhci11102 1 > lapic0: timer1246549 1994 > lapic1: timer1246427 1994 > Total2556893 4091 > > > The only relevant conflict I could see is irc 20; but I had already > tested that by removing fxp0 from the kernel. I wonder if USB is causing the problem all on its own..since that was the culprit in other situations when it was being triggered by virtue of interrupt sharing. Any chance you can try a non-USB mouse and remove USB from your kernel? Kris pgpukloupQ9WC.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: Show me vmstat -i now. interrupt total rate irq1: atkbd0 586 0 irq13: npx01 0 irq14: ata0 94 0 irq17: wi054 0 irq20: fxp0 atapci162079 99 irq21: uhci0 ehci0 1 0 irq22: uhci11102 1 lapic0: timer1246549 1994 lapic1: timer1246427 1994 Total2556893 4091 The only relevant conflict I could see is irc 20; but I had already tested that by removing fxp0 from the kernel. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 07:17:53AM +0200, Matthias Buelow wrote: > Kris Kennaway wrote: > > >>I've now disabled the sound chip in the BIOS, no change. > >But is the driver still attaching? > > No, and I now have disabled loading the module at boot aswell. Still no > difference. I would also think that if that were the cause, the > situation would be a lot worse on the notebook, where a lot more devices > share one interrupt. But on the notebook (much slower machine), it > isn't quite as bad as on the desktop machine. Show me vmstat -i now. Kris pgplSSchM0KVP.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: I've now disabled the sound chip in the BIOS, no change. But is the driver still attaching? No, and I now have disabled loading the module at boot aswell. Still no difference. I would also think that if that were the cause, the situation would be a lot worse on the notebook, where a lot more devices share one interrupt. But on the notebook (much slower machine), it isn't quite as bad as on the desktop machine. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 06:51:52AM +0200, Matthias Buelow wrote: > Kris Kennaway wrote: > > >>irq11: cbb0 cbb1++* 373638 12 > >What else is on irq11? > > Hmm.. uhm! > > uhci0, pcm0, fxp0 and wi0... :-} > > Is the "++*" thing notation for "there's more stuff but I won't show you"? Yes. Laptops tend to be bad for putting everything on one IRQ. Kris pgpHyHZy458R3.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 06:55:40AM +0200, Matthias Buelow wrote: > Kris Kennaway wrote: > > >I think it's your mouse fighting with your sound card for Giant. > > I've now disabled the sound chip in the BIOS, no change. But is the driver still attaching? Kris pgp55i58bFJOT.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: I think it's your mouse fighting with your sound card for Giant. I've now disabled the sound chip in the BIOS, no change. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: irq11: cbb0 cbb1++* 373638 12 What else is on irq11? Hmm.. uhm! uhci0, pcm0, fxp0 and wi0... :-} Is the "++*" thing notation for "there's more stuff but I won't show you"? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 06:38:59AM +0200, Matthias Buelow wrote: > Kris Kennaway wrote: > > >I think it's your mouse fighting with your sound card for Giant. > > And why does it also happen (if not as badly but still) on my notebook > where there's no such conflict? > > interrupt total rate > irq0: clk2959195 99 > irq1: atkbd0 34101 1 > irq6: fdc0 4 0 > irq11: cbb0 cbb1++* 373638 12 > irq12: psm0 267 0 > irq13: npx01 0 > irq14: ata0 374788 12 > Total3741994126 What else is on irq11? Kris pgpwY0RYco5Lg.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: I think it's your mouse fighting with your sound card for Giant. And why does it also happen (if not as badly but still) on my notebook where there's no such conflict? interrupt total rate irq0: clk2959195 99 irq1: atkbd0 34101 1 irq6: fdc0 4 0 irq11: cbb0 cbb1++* 373638 12 irq12: psm0 267 0 irq13: npx01 0 irq14: ata0 374788 12 Total3741994126 mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 06:20:55AM +0200, Matthias Buelow wrote: > Joseph Koshy wrote: > > >You may want to try without options WITNESS, INVARIANTS and > >INVARIANT_SUPPORT. > > Ok, I've done this. Symptoms are now about equal to 5.4-STABLE. I think it's your mouse fighting with your sound card for Giant. Kris pgpnKgz4arORr.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Joseph Koshy wrote: You may want to try without options WITNESS, INVARIANTS and INVARIANT_SUPPORT. Ok, I've done this. Symptoms are now about equal to 5.4-STABLE. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: pcm0 and uhci3 share an interrupt on your system, and both are under Giant, so they'll fight over it when one receives an interrupt, and nothing else can run in the kernel when that is happening. Do you need USB support? If not, get rid of it. Well.. the USB mouse needs it, I guess... mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 05:45:29AM +0200, Matthias Buelow wrote: Once you remove the debugging options.. > uhci3: [GIANT-LOCKED] > pcm0: [GIANT-LOCKED] > interrupt total rate > irq1: atkbd01856 1 > irq13: npx01 0 > irq14: ata0 94 0 > irq17: wi0 506 0 > irq20: fxp0 atapci173527 72 > irq21: uhci0 ehci0 1 0 > irq22: uhci14876 4 > irq23: pcm0 uhci3 1008 0 pcm0 and uhci3 share an interrupt on your system, and both are under Giant, so they'll fight over it when one receives an interrupt, and nothing else can run in the kernel when that is happening. Do you need USB support? If not, get rid of it. Kris pgpwHLLSMHLYP.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 05:45:29AM +0200, Matthias Buelow wrote: > Kris Kennaway wrote: > > >OK, thanks for confirming. The next step is for you to try 6.0 with > >debug.mpsafevfs=1 on a machine that exhibits the problem under 5.4, so > >we can test whether the problem is caused by VFS being under Giant on > >5.4. > > I have now built 6.0-current from yesterday's source, verified that > debug.mpsafevfs=1, and unpacked the firefox source. > Unfortunately your hypothesis didn't hold. In fact, it's a lot worse > than on 5.4-STABLE. Plus, even operations like bulk-rm'ing the unpacked > firefox tree make X11 crawl and stutter, something that didn't have any > observable effect on 5.4-STABLE. Maybe the dmesg output is of some help: > > > Copyright (c) 1992-2005 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 6.0-CURRENT #0: Wed May 25 05:00:48 CEST 2005 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. *Ahem* Kris pgpaPQmQMf3X1.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
> FreeBSD 6.0-CURRENT #0: Wed May 25 05:00:48 CEST 2005 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. WITNESS will cause terrible slowdowns. You may want to try without options WITNESS, INVARIANTS and INVARIANT_SUPPORT. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: OK, thanks for confirming. The next step is for you to try 6.0 with debug.mpsafevfs=1 on a machine that exhibits the problem under 5.4, so we can test whether the problem is caused by VFS being under Giant on 5.4. I have now built 6.0-current from yesterday's source, verified that debug.mpsafevfs=1, and unpacked the firefox source. Unfortunately your hypothesis didn't hold. In fact, it's a lot worse than on 5.4-STABLE. Plus, even operations like bulk-rm'ing the unpacked firefox tree make X11 crawl and stutter, something that didn't have any observable effect on 5.4-STABLE. Maybe the dmesg output is of some help: Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #0: Wed May 25 05:00:48 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 Features=0xbfebfbff Features2=0x441d,MON,DS_CPL,CNTX-ID,> Hyperthreading: 2 logical CPUs real memory = 1072201728 (1022 MB) avail memory = 1040392192 (992 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 5 on acpi0 pci_link2: irq 5 on acpi0 pci_link3: on acpi0 pci_link4: irq 9 on acpi0 pci_link5: irq 10 on acpi0 pci_link6: irq 9 on acpi0 pci_link7: irq 3 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci1: at device 0.1 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 uhci0: port 0xff80-0xff9f irq 21 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xff60-0xff7f irq 22 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xff20-0xff3f irq 23 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xffa80800-0xffa80bff irq 21 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib3: at device 30.0 on pci0 pci3: on pcib3 wi0: mem 0xd800-0xd8000fff irq 17 at device 1.0 on pci3 wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.9) wi0: Ethernet address: 00:0d:54:aa:62:12 fxp0: port 0xccc0-0xccff mem 0xdfbff000-0xdfbf irq 20 at device 8.0 on pci3 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:11:11:65:21:d4 pci0: at device 30.2 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf irq 16 at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf irq 20 at device 31.2 on pci0 atapci1: failed to enable memory mapping! ata2: on atapci1 ata3: on atapci1 pci0: at device 31.3 (no driver attached) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A pmtimer0 on isa0 orm0: at iomem 0xc-0xce7ff,0xce800-
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Tue, May 24, 2005 at 11:50:07PM +0200, Matthias Buelow wrote: > Kris Kennaway wrote: > > >>Hmm... atapci1 is shared with fxp0 on irq 20.. does fxp0 also require > >>the giant lock? > > > >I don't think so..but the shared interrupt might still be causing some > >other problem. Try compiling a kernel without fxp support and see if > >you still have the interactive problems under disk load. > > Ok, I now have tried a) with HTT switched off in BIOS, b) with HTT off > and without the fxp driver (so that atapci1 is the only driver on irq > 20) and c) on a Compaq notebook, all machines running 5.4-stable. > Basically, the problem occurs in all 3 scenarios. OK, thanks for confirming. The next step is for you to try 6.0 with debug.mpsafevfs=1 on a machine that exhibits the problem under 5.4, so we can test whether the problem is caused by VFS being under Giant on 5.4. Kris pgpJPfC3g04Qf.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, May 24, 2005 at 05:23:59PM -0400, Lowell Gilbert wrote: > Scott Robbins <[EMAIL PROTECTED]> writes: > > > True, but in general, having gotten used to LINT, usually, I would just > > check notes for syntax--for instance, I might see something about > > PREEMPTION and just do (while in i386/conf) grep PREEMPT NOTES. > > Don't forget sys/conf/NOTES, either. [which includes PREEMPTION, > albeit without any useful info] Sorry, perhaps this wasn't clear, I must have snipped too much--that's what we were discussing, the fact that many people miss sys/conf/NOTES. :) > - -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Xander: Well, yeah. I'd give anything to be able to turn invisible. I wouldn't use my powers to beat people up, but use my powers to protect the girl's locker room. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCk6H1+lTVdes0Z9YRAkwFAJ9xv92iEWE/4uMbGEPqDJhij6F3aACgv0cM /+Tc0XN6NzWJ4r/4UD/kHUw= =Swm0 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: Hmm... atapci1 is shared with fxp0 on irq 20.. does fxp0 also require the giant lock? I don't think so..but the shared interrupt might still be causing some other problem. Try compiling a kernel without fxp support and see if you still have the interactive problems under disk load. Ok, I now have tried a) with HTT switched off in BIOS, b) with HTT off and without the fxp driver (so that atapci1 is the only driver on irq 20) and c) on a Compaq notebook, all machines running 5.4-stable. Basically, the problem occurs in all 3 scenarios. However, while cases a) and b) don't seem to be any different from the original scenario, it is a lot less pronounced on the notebook (c). In c) the mouse cursor doesn't really jump but only "feels" a bit like moving thru syrup, and audio playback (from a remote stream) stops only for fractions of a second. in a) and b), when moving the mouse, the mouse cursor literally jumps around on the screen for several seconds many times during disk i/o, and audio playback stops for ca. 1 second pauses and starts stuttering, like in the original scenario. Curiously I apparently can only reproduce it when untarring large archives like firefox/thunderbird. An ordinary find, or removing the stuff again doesn't seem to show any of those symptoms. The machines are: Intel ICH6-based desktop machine, 3ghz p4 ht, sata disk, and Intel 440BX, 850mhz p3 notebook, udma33 ata disk. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Matthias Buelow wrote: Scott Robbins wrote: Judging from the forums and various other things, it seems that a lot of people aren't aware of the second NOTES file. (Of course, you can do make LINT while in /conf, which I blush to admit, is what I did before I realized the existance of the second NOTES file. :) Hmm, I didn't know about it either, even though it is referenced at the top of the machdep NOTES file (but who reads that stuff.. ;) yeah, you're right, it's there and now i remember i went through it a few months ago when i was configuring my first bsd installation. (i'm sorry, my memory is not very good anymore.) the reason i skipped it is most likely that it's under section "SMP Debugging Options" which didn't sound to me to be (useful) for my laptop. i'll try it now. thank you all for you responses! martin mkb. ___ 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]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Scott Robbins <[EMAIL PROTECTED]> writes: > True, but in general, having gotten used to LINT, usually, I would just > check notes for syntax--for instance, I might see something about > PREEMPTION and just do (while in i386/conf) grep PREEMPT NOTES. Don't forget sys/conf/NOTES, either. [which includes PREEMPTION, albeit without any useful info] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway [EMAIL PROTECTED] wrote: > > I didn't see any visible difference, in the given scenario of > > uncompressing firefox's sources, when tried mpsafevfs's patches when > > they got announced on [EMAIL PROTECTED] > There have been a *lot* of changes in this area since the initial > patches (i.e. continued removal of Giant), so you'd really need to > re-test on a recent version of 6.0 to be definitive. Could be. Though given my present experience with 5.4-RELEASE, where I have no problems on my current hardware, I'd assume the issues I used to observe were not really VFS/Giant related. And yes, I ruled the USB issue out as well. I will try to put my hands on the mentioned AMD box once again, to run some current 6.0 on it. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, May 24, 2005 at 12:27:21PM -0700, Freddie Cash wrote: > On May 24, 2005 12:14 pm, Scott Robbins wrote: > > > > The other is for items that apply to all CPU architectures, and is > > > located at /usr/src/sys/conf/NOTES. > > > > You have to read both. The PREEMPTION option is in the second file > > > above. > > > Judging from the forums and various other things, it seems that a lot of > > people aren't aware of the second NOTES file. (Of course, you can do > > make LINT while in /conf, which I blush to admit, is what I did > > before I realized the existance of the second NOTES file. :) > > From the top of /usr/src/sys/i386/conf/NOTES: > > # NOTES -- Lines that can be cut/pasted into kernel and hints configs. > # > # This file contains machine dependent kernel configuration notes. For > # machine independent notes, look in /sys/conf/NOTES. > > Like they say, doesn't matter how good the documentation is if nobody reads > it fully. :) True, but in general, having gotten used to LINT, usually, I would just check notes for syntax--for instance, I might see something about PREEMPTION and just do (while in i386/conf) grep PREEMPT NOTES. What's the old Calvin and Hobbes line? "Have you looked at the manual?" "WHAT? Do I look like a sissy?" You're right of course, Fred, but in honesty, it's been awhile since I read NOTES (or LINT in the old days) top to bottom. Heh, I was more careful when I was a complete novice--err, not that I'm any sort of expert now. :) - -- Scott Robbins GPG KeyID EB3467D6 ( 1B848 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCk5CH+lTVdes0Z9YRAoHTAJ9kU9sF9u0fUE5bWOoImb+TdkutZwCbBguG UuC9okCTDRkQ33FXeyU9usg= =Fh5s -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Tue, May 24, 2005 at 10:23:28PM +0200, Matthias Buelow wrote: > Kris Kennaway wrote: > > > But are any IRQs shared? > > Hmm... atapci1 is shared with fxp0 on irq 20.. does fxp0 also require > the giant lock? I don't think so..but the shared interrupt might still be causing some other problem. Try compiling a kernel without fxp support and see if you still have the interactive problems under disk load. Kris pgpF89CGEcCv4.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: > But are any IRQs shared? Hmm... atapci1 is shared with fxp0 on irq 20.. does fxp0 also require the giant lock? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Tue, May 24, 2005 at 10:18:54PM +0200, Matthias Buelow wrote: > Max Laier wrote: > > > I have seen this on my box. Disabling one of the USB-ports solved the > > problem. I was seeing very high IRQ-rates. Check $vmstat -i during the > > process to see if you have abnormal high rate jumps. It might be that we > > must investigate some of our drivers to play nice with each other. > > Interrupt rates were normal. But are any IRQs shared? Kris pgpmemAkAya00.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Max Laier wrote: > I have seen this on my box. Disabling one of the USB-ports solved the > problem. I was seeing very high IRQ-rates. Check $vmstat -i during the > process to see if you have abnormal high rate jumps. It might be that we > must investigate some of our drivers to play nice with each other. Interrupt rates were normal. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Tue, May 24, 2005 at 09:41:29PM +0200, Max Laier wrote: > On Monday 23 May 2005 23:21, Matthias Buelow wrote: > > Kris Kennaway wrote: > > > One thing that probably confuses and misleads a lot of people is when > > > they build world or a kernel and notice that it's taking much longer > > > than it did under 4.x, so they assume this means that 5.x is slower > > > than 4.x. It doesn't. What it means is that 5.x and 4.x have > > > different C compilers, and gcc 3.x is much slower at compiling code > > > than gcc 2.x. You have to be very careful to draw conclusions based > > > on subjective assessments like this. > > > > Another thing might be that interactive response time seems to be worse. > > While I (or rather ports) unpack the firefox/thunderbird source, the > > machine is pretty much bogged down (mouse cursor jumps around, audio > > stutters...). Haven't seen that on FreeBSD since the 386 days. > > I have seen this on my box. Disabling one of the USB-ports solved the > problem. I was seeing very high IRQ-rates. Check $vmstat -i during the > process to see if you have abnormal high rate jumps. It might be that we > must investigate some of our drivers to play nice with each other. Actually, this is something that others have seen too (e.g. rwatson). Specifically, if you have USB support enabled in your kernel and a USB device shares an IRQ with some other device then every interrupt on those devices causes USB to acquire Giant, significantly degrading system performance. Kris pgpr3CXUGRK32.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Monday 23 May 2005 23:21, Matthias Buelow wrote: > Kris Kennaway wrote: > > One thing that probably confuses and misleads a lot of people is when > > they build world or a kernel and notice that it's taking much longer > > than it did under 4.x, so they assume this means that 5.x is slower > > than 4.x. It doesn't. What it means is that 5.x and 4.x have > > different C compilers, and gcc 3.x is much slower at compiling code > > than gcc 2.x. You have to be very careful to draw conclusions based > > on subjective assessments like this. > > Another thing might be that interactive response time seems to be worse. > While I (or rather ports) unpack the firefox/thunderbird source, the > machine is pretty much bogged down (mouse cursor jumps around, audio > stutters...). Haven't seen that on FreeBSD since the 386 days. I have seen this on my box. Disabling one of the USB-ports solved the problem. I was seeing very high IRQ-rates. Check $vmstat -i during the process to see if you have abnormal high rate jumps. It might be that we must investigate some of our drivers to play nice with each other. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpzp6qOjgqMd.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On May 24, 2005 12:14 pm, Scott Robbins wrote: > On Tue, May 24, 2005 at 12:07:35PM -0700, Freddie Cash wrote: > > There are two NOTES files for each CPU architecture. > > One is for the CPU architecture dependent items and is located > > at /usr/src/sys//conf/NOTES Just replace with the CPU > > architecture (i386, amd64, etc). > > The other is for items that apply to all CPU architectures, and is > > located at /usr/src/sys/conf/NOTES. > > You have to read both. The PREEMPTION option is in the second file > > above. > Judging from the forums and various other things, it seems that a lot of > people aren't aware of the second NOTES file. (Of course, you can do > make LINT while in /conf, which I blush to admit, is what I did > before I realized the existance of the second NOTES file. :) From the top of /usr/src/sys/i386/conf/NOTES: # NOTES -- Lines that can be cut/pasted into kernel and hints configs. # # This file contains machine dependent kernel configuration notes. For # machine independent notes, look in /sys/conf/NOTES. # # $FreeBSD: src/sys/i386/conf/NOTES,v 1.1168.2.5.2.2 2005/05/01 05:38:13 dwhite Exp $ # Like they say, doesn't matter how good the documentation is if nobody reads it fully. :) -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Scott Robbins wrote: > Judging from the forums and various other things, it seems that a lot of > people aren't aware of the second NOTES file. (Of course, you can do > make LINT while in /conf, which I blush to admit, is what I did > before I realized the existance of the second NOTES file. :) Hmm, I didn't know about it either, even though it is referenced at the top of the machdep NOTES file (but who reads that stuff.. ;) mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
Mike Jakubik wrote: Could someone point me to a resource that outlines the expected supported lifetime of all the branches? Can't find anything concrete on the webpage. I'm developing a product, which i hope will run on FreeBSD. However the rapid development of 5, and now 6 arriving out in a few months has me worried if FreeBSD will be the right choice short and long term. I have even considered using 4.11 for its stability and speed on single processor systems, but I'm worried that some ports/hw will not be supported. The recent amount of problems with 5 has me a little discouraged too, and even considering Linux as an alternative. Hopefully that wont be the case, but a clear outline of whats to come would be very helpful in the decision making. Thanks. First of all, as the release engineer, I cannot stress enough that 6.0 is only an evolutionary step from 5.x. It's natural to assume that every major version change indicates major (and majorly destabilizing) changes, but that is exactly what we are trying to get away from now. When people ask what the future of 5.x is, my answer is "6.x" because that's exactly what it is: a continuation and refinement of what we did with 5.x, with a few needed architecture changes and features. We are going to release 6.0 within the next few months, and 6.1 4 months after that. There will be a 5.5 release inbetween there just to wrap up that branch and provide users a bridge for 6.x. I don't expect there to be any 5.x releases after 5.5 because there simply won't be anything left to offer in that branch that isn't in 6.x. The 6.x transition will not have the handicaps that the 5.x transition had for users. It does not have a significantly different compiler that requires major porting work for user applications. It does not have a dozen new experimental features that are still being debugged. The only really new and experimental feature is the SMP VFS work, but that has been undergoing a significant amount of testing, and it can be turned off if need be. This is in sharp contrast to 5.x that had so many overlapping experimental areas that it was hard to test, isolate and fix problems. I think that we've gotten over most of the stability and performance hurdles of 5.x. We have a complete OS, not just a kernel, and it has more components than the 4.x OS. But despite that, most bugs reported on this list seem to get solved fairly quickly, either with advice from others or with a commit to the source tree. We have a number of very strong and very active ports and source tree committers that are doing a very good job of refining the system, and I expect that to continue. More bug reports are always welcome, and if you feel that there is a bug that isn't getting attention that is critical for 6.0, email [EMAIL PROTECTED] about it, or email me personally. As for performance, Kris has shown that the 5.x/6.x performance penalty is now much more of a myth than reality. SMP on 6.x is significantly more scalable and high performance than anything we've released before. We are finally starting to see the benefits of our SMPng design. Most of the infrastructure work is done, so 6.x will be about refining it, locking down more peripheral drivers and components, and tending to the general details that have fallen behind in 5.x. It's going to be a very good release series. I understand that there are some specific reasons for some people to stick with 4.x. There were people that stuck with 2.2.x back during the 3.x and 4.x days because they also had specific needs. I think that this is fine if done for the right reasons, and I'm glad that those people are willing to stick with FreeBSD instead of looking elsewhere. However, if there is anything that we can do to help with the transition forward to 5.x/6.x, please let me know. Again, please don't take the abrupt switch to 6.0 to mean that 5.x is flawed or that 6.x will also have a short lifespan. The real purpose of the switch is nothing but positive; it'll keep us focused and prevent us from overreaching and overextending ourselves. It's a very good and very postive strategy. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, May 24, 2005 at 12:07:35PM -0700, Freddie Cash wrote: > > There are two NOTES files for each CPU architecture. > > One is for the CPU architecture dependent items and is located > at /usr/src/sys//conf/NOTES Just replace with the CPU > architecture (i386, amd64, etc). > > The other is for items that apply to all CPU architectures, and is located > at /usr/src/sys/conf/NOTES. > > You have to read both. The PREEMPTION option is in the second file above. Judging from the forums and various other things, it seems that a lot of people aren't aware of the second NOTES file. (Of course, you can do make LINT while in /conf, which I blush to admit, is what I did before I realized the existance of the second NOTES file. :) - -- Scott GPG KeyID EB3467D6 ( 1B848 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Xander: How could you let her go? Giles: As the soon-to-be-purple area on my jaw will attest, I did not 'let' her go. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCk30Q+lTVdes0Z9YRAomMAKCoXJWOeSQCAH1m2T4aad2v8T6ooACfcXiV XBLgHmlE7XJKWWCccAv2+tU= =1rAL -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Tue, May 24, 2005 at 08:39:23PM +0200, martinko wrote: > Kris Kennaway wrote: > > > >Also try defining PREEMPTION in your kernel on 5.x and above (if you > >are running i386 or amd64). There have been very occasional reports > >of panics with this option enabled (although I use it everywhere and > >have not seen problems on my heavily loaded machines), but interactive > >response should be much better. > > > > kris, > > i cannot find (a description of) PREEMPTION in NOTES or GENERIC (on 5.4 > on i386). > > am i missing something? Surely :) Kris pgpUei3GE3HF1.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On May 24, 2005 11:39 am, martinko wrote: > Kris Kennaway wrote: > > Also try defining PREEMPTION in your kernel on 5.x and above (if you > > are running i386 or amd64). There have been very occasional reports > > of panics with this option enabled (although I use it everywhere and > > have not seen problems on my heavily loaded machines), but interactive > > response should be much better. > i cannot find (a description of) PREEMPTION in NOTES or GENERIC (on 5.4 > on i386). > am i missing something? There are two NOTES files for each CPU architecture. One is for the CPU architecture dependent items and is located at /usr/src/sys//conf/NOTES Just replace with the CPU architecture (i386, amd64, etc). The other is for items that apply to all CPU architectures, and is located at /usr/src/sys/conf/NOTES. You have to read both. The PREEMPTION option is in the second file above. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's in /usr/src/sys/conf/NOTES. I think this is due to it being an architecture independent option. - -- Regards, Pedro. martinko wrote: > Kris Kennaway wrote: > >> >> Also try defining PREEMPTION in your kernel on 5.x and above (if you >> are running i386 or amd64). There have been very occasional reports >> of panics with this option enabled (although I use it everywhere and >> have not seen problems on my heavily loaded machines), but interactive >> response should be much better. >> > > kris, > > i cannot find (a description of) PREEMPTION in NOTES or GENERIC (on 5.4 > on i386). > > am i missing something? > > cheers, > > martin > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCk07pwJC0A/CNpUURAu/qAKCjdfHNlBThgfJJKR+rblvSovMhJgCg3x6D EbGdm91C7sjI2vKKZ5X9V2w= =4Jgq -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: Also try defining PREEMPTION in your kernel on 5.x and above (if you are running i386 or amd64). There have been very occasional reports of panics with this option enabled (although I use it everywhere and have not seen problems on my heavily loaded machines), but interactive response should be much better. kris, i cannot find (a description of) PREEMPTION in NOTES or GENERIC (on 5.4 on i386). am i missing something? cheers, martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On May 24, 2005 09:32 am, you wrote: > Freddie Cash wrote: > > The laptop has an ATI IXP chipset, which means the HD is detected and > > run as a generic UDMA33 device. The kernel is using the 4BSD > > scheduler with PREEMPTION enabled, all debugging hints disabled, and > > all the mpsafe sysctls enabled. > Hmm.. maybe the disk (interface) is just too slow to trigger this when > running in UDMA33 (and a slow notebook disk).. I have observed it on a > SATA Seagate setup (on ICH6 chipset). Just a wild guess. That is a possibility, yes. Next time I upgrade Firefox or Thunderbird, I'll have to watch the processor and disk usage to see if that's the case. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Tue, May 24, 2005 at 06:32:28PM +0200, Matthias Buelow wrote: > Freddie Cash wrote: > > > The laptop has an ATI IXP chipset, which means the HD is detected and run > > as a generic UDMA33 device. The kernel is using the 4BSD scheduler with > > PREEMPTION enabled, all debugging hints disabled, and all the mpsafe > > sysctls enabled. > > Hmm.. maybe the disk (interface) is just too slow to trigger this when > running in UDMA33 (and a slow notebook disk).. I have observed it on a > SATA Seagate setup (on ICH6 chipset). Just a wild guess. I'd expect a slow disk to make worse the problem of blocking waiting for disk I/O. Kris pgpdGYaE4Vnq8.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Freddie Cash wrote: > The laptop has an ATI IXP chipset, which means the HD is detected and run > as a generic UDMA33 device. The kernel is using the 4BSD scheduler with > PREEMPTION enabled, all debugging hints disabled, and all the mpsafe > sysctls enabled. Hmm.. maybe the disk (interface) is just too slow to trigger this when running in UDMA33 (and a slow notebook disk).. I have observed it on a SATA Seagate setup (on ICH6 chipset). Just a wild guess. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On May 23, 2005 02:31 pm, Kris Kennaway wrote: > On Mon, May 23, 2005 at 11:21:13PM +0200, Matthias Buelow wrote: > > Another thing might be that interactive response time seems to be > > worse. While I (or rather ports) unpack the firefox/thunderbird > > source, the machine is pretty much bogged down (mouse cursor jumps > > around, audio stutters...). Haven't seen that on FreeBSD since the > > 386 days. > I don't run FreeBSD on my desktop machines so I haven't seen this > myself. One obvious guess is that it's due to VFS being under Giant, > which causes lots of contention with other subsystems that also > require Giant, and therefore introduces latency. If so, you'd see a > substantial performance improvement on 6.0 with debug.mpsafevfs=1. > This option isn't yet ready for production use (especially on SMP > machines) since it still contains bugs, but it would be interesting if > someone who sees this problem could test it on 6.0. > Any takers? I haven't run any actual benchmarks, but I have 6-CURRENT (May 20) on my 2.4 GHz Celeron laptop (1 GB RAM), a Toshiba Satellite A60. Installing ports, even large ones like firefox, thunderbird, openoffice.org, java, xorg, or kde (that take a long time to uncompress and/or compile) doesn't affect my usage of the computer, even when in KDE. The laptop has an ATI IXP chipset, which means the HD is detected and run as a generic UDMA33 device. The kernel is using the 4BSD scheduler with PREEMPTION enabled, all debugging hints disabled, and all the mpsafe sysctls enabled. The only time I see any kind of slowdown or stuttering when in X is if I have multiple compiles running in the background (usually a buildworld and a portupgrade session) without using nice. If doing a single port install (no nice values) in the background, I don't notice it. The only other app that is slow on this system is Firefox (but that's slow on every system I've tried, FreeBSD, Linux, and Windows), which is why I tend to use Konqueror as much as possible. If anyone wants actual benchmark results or timing tests, they'll have to let me know what to run, as I've never done any benchmarking before. All I can say is that I don't notice any slowdowns or stuttering or anything like that on this system. And it's my do-everything workstation (plugged into a 21" monitor, USB mouse and keyboard when at work). -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Tue, May 24, 2005 at 04:37:26PM +0200, Krzysztof Kowalik wrote: > Kris Kennaway [EMAIL PROTECTED] wrote: > > [...] One obvious guess is that it's due to VFS being under Giant, > > which causes lots of contention with other subsystems that also > > require Giant, and therefore introduces latency. If so, you'd see a > > substantial performance improvement on 6.0 with debug.mpsafevfs=1. > > I didn't see any visible difference, in the given scenario of > uncompressing firefox's sources, when tried mpsafevfs's patches when > they got announced on [EMAIL PROTECTED] There have been a *lot* of changes in this area since the initial patches (i.e. continued removal of Giant), so you'd really need to re-test on a recent version of 6.0 to be definitive. Kris pgpqJUV4FMdzR.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway [EMAIL PROTECTED] wrote: > [...] One obvious guess is that it's due to VFS being under Giant, > which causes lots of contention with other subsystems that also > require Giant, and therefore introduces latency. If so, you'd see a > substantial performance improvement on 6.0 with debug.mpsafevfs=1. I didn't see any visible difference, in the given scenario of uncompressing firefox's sources, when tried mpsafevfs's patches when they got announced on [EMAIL PROTECTED] The funny thing is, that I saw it on my Athlon XP box *very* visibly, while I it's quite ok on my current workstation, which is Celeron based (and yes, it's much slower, CPU wise, than the Athlon machine). Perhaps some funny chipset issue? Old box: FreeBSD 5.3-RELEASE #2: Wed Nov 17 00:19:56 CET 2004 [...] ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP 2000+ (1668.71-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc040 real memory = 1073725440 (1023 MB) avail memory = 1041154048 (992 MB) [...] emu10kx0: port 0x9400-0x941f irq 19 at device 12.0 on pci0 pcm0: on emu10kx0 pcm0: [...] atapci0: port 0xa400-0xa40f,0xa800-0xa803,0xb000-0xb007,0xb400-0xb403,0xb800-0xb807 mem 0xe680-0xe6803fff irq 19 at device 6.0 on pci0 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 atapci1: port 0x8400-0x840f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 17.1 on pci0 ata0: channel #0 on atapci1 ata1: channel #1 on atapci1 ad0: 152627MB [310101/16/63] at ata0-master UDMA100 ad1: 190782MB [387621/16/63] at ata0-slave UDMA100 ar0: 57220MB [7294/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad5 at ata2-slave [...] New box: FreeBSD 5.4-RELEASE-p1 #0: Sat May 14 18:43:25 CEST 2005 [...] CPU: Intel(R) Celeron(TM) CPU1200MHz (1202.73-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383f9ff real memory = 536805376 (511 MB) avail memory = 515629056 (491 MB) [...] atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 [...] pcm0: port 0xe000-0xe03f,0xdc00-0xdcff irq 7 at device 31.5 on pci0 pcm0: [...] ad0: 76319MB [155061/16/63] at ata0-master UDMA100 ad1: 152627MB [310101/16/63] at ata0-slave UDMA100 [...] So they are, unfortunately, a little bit different machines. And no, I had no chance to try 5.4-RELEASE on the amd one. In general, I find 5.4-RELEASE performing better, if I can say that without doing any real benchmarking, than any previous 5.x. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On May 23, 2005, at 3:51 PM, Kris Kennaway wrote: actually benchmarked this on the package build machines, and found that 5.4 outperforms 4.11 by at least 10% when performing identical workloads on identical UP hardware :-) I have a pair of twin dual opteron boxes built about 1 month apart. One is about 5% faster than the other running 5.4-RELEASE-p1. No idea why. Vivek Khera, Ph.D. +1-301-869-4449 x806 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
On Mon, May 23, 2005 at 08:17:37PM -0700, Jon Dama wrote: > It might be beneficial (pipe-dream perhaps) if the all the BSDs coalesced > around one port/packaging system. I hear that netbsd's port system has > the metadata necessary to support different OSs and different OS versions > within one coherent system. Not likely to happen, although pkgsrc does support running on FreeBSD. Kris pgpF3K8loiV5f.pgp Description: PGP signature
Re: Lifetime of FreeBSD branches
On 2005.05.23 17:38:12 -0400, Mike Jakubik wrote: > On Mon, May 23, 2005 5:08 pm, Simon L. Nielsen said: > > On 2005.05.23 16:51:18 -0400, Mike Jakubik wrote: > >> > >> Thanks for the info guys. Does this "security support" also mean that > >> current ports will be compatible with the release? > > > > No, there are no guarantees about that. The ports/ people generally > > try to make things work with older releases, but there are no gurantees > > there. It's simply too much work to make such guarantees, and this is > > after all an volunteer project (for most parts anyway). See also > > http://www.freebsd.org/ports/ for the "official" statement. > > Right, i didnt think so. Debian is a volunteer project too, and their > packaging system supports all of their branches. But see how many branches they have to support - not many. It's quite a different question when you have new branches every < 6 months compared to when you have one every few years. > I guess i should look > into rolling my own packages, to be sure. And yes, i realize that we just > dont have an infrastructure for something like this. Well, you always have the option to simply backport whatever fixes you want yourself. There are a good chance that most things will work for quite a while. -- Simon L. Nielsen pgp61g1NHKYHu.pgp Description: PGP signature
Re: Lifetime of FreeBSD branches
It might be beneficial (pipe-dream perhaps) if the all the BSDs coalesced around one port/packaging system. I hear that netbsd's port system has the metadata necessary to support different OSs and different OS versions within one coherent system. What do you think about the relative strengths of pkgsrc and the FreeBSD ports system? -Jon On Mon, 23 May 2005, Kris Kennaway wrote: > On Tue, May 24, 2005 at 10:45:48AM +0900, Joel wrote: > > Random comment from the peanut gallery, but ... > > > > > >> Thanks for the info guys. Does this "security support" also mean that > > > >> current ports will be compatible with the release? > > > > > > > > No, there are no guarantees about that. The ports/ people generally > > > > try to make things work with older releases, but there are no gurantees > > > > there. It's simply too much work to make such guarantees, and this is > > > > after all an volunteer project (for most parts anyway). See also > > > > http://www.freebsd.org/ports/ for the "official" statement. > > > > > > Right, i didnt think so. Debian is a volunteer project too, and their > > > packaging system supports all of their branches. I guess i should look > > > into rolling my own packages, to be sure. And yes, i realize that we just > > > dont have an infrastructure for something like this. > > > > I'm thinking that, if a company really doesn't have the infrastructure, > > there are several good options. You mention Linux. MacOSX is closer to > > the BSDs than Linux in many ways, tends to have relatively long-term > > stability, and you can pay Apple for a rather high level of support if > > you join their developer's program. > > > > The best option, however, may be to invest in the infrastructure -- a > > long term relationship with a qualified contractor, or even an employee > > whose primary duty would be to (learn how to) do the heavy lifting on > > backporting and upgrading. That way, the OS itself becomes more a part > > of the company's resources. > > Didn't someone announce a few months ago that they were going to work > on supporting ports with older releases? I'm sure they'd welcome > support, whether financial, material or otherwise. > > Kris > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
On Tue, May 24, 2005 at 10:45:48AM +0900, Joel wrote: > Random comment from the peanut gallery, but ... > > > >> Thanks for the info guys. Does this "security support" also mean that > > >> current ports will be compatible with the release? > > > > > > No, there are no guarantees about that. The ports/ people generally > > > try to make things work with older releases, but there are no gurantees > > > there. It's simply too much work to make such guarantees, and this is > > > after all an volunteer project (for most parts anyway). See also > > > http://www.freebsd.org/ports/ for the "official" statement. > > > > Right, i didnt think so. Debian is a volunteer project too, and their > > packaging system supports all of their branches. I guess i should look > > into rolling my own packages, to be sure. And yes, i realize that we just > > dont have an infrastructure for something like this. > > I'm thinking that, if a company really doesn't have the infrastructure, > there are several good options. You mention Linux. MacOSX is closer to > the BSDs than Linux in many ways, tends to have relatively long-term > stability, and you can pay Apple for a rather high level of support if > you join their developer's program. > > The best option, however, may be to invest in the infrastructure -- a > long term relationship with a qualified contractor, or even an employee > whose primary duty would be to (learn how to) do the heavy lifting on > backporting and upgrading. That way, the OS itself becomes more a part > of the company's resources. Didn't someone announce a few months ago that they were going to work on supporting ports with older releases? I'm sure they'd welcome support, whether financial, material or otherwise. Kris pgpih2tYwnICs.pgp Description: PGP signature
Re: Lifetime of FreeBSD branches
Random comment from the peanut gallery, but ... (B (B> >> Thanks for the info guys. Does this "security support" also mean that (B> >> current ports will be compatible with the release? (B> > (B> > No, there are no guarantees about that. The ports/ people generally (B> > try to make things work with older releases, but there are no gurantees (B> > there. It's simply too much work to make such guarantees, and this is (B> > after all an volunteer project (for most parts anyway). See also (B> > http://www.freebsd.org/ports/ for the "official" statement. (B> (B> Right, i didnt think so. Debian is a volunteer project too, and their (B> packaging system supports all of their branches. I guess i should look (B> into rolling my own packages, to be sure. And yes, i realize that we just (B> dont have an infrastructure for something like this. (B (BI'm thinking that, if a company really doesn't have the infrastructure, (Bthere are several good options. You mention Linux. MacOSX is closer to (Bthe BSDs than Linux in many ways, tends to have relatively long-term (Bstability, and you can pay Apple for a rather high level of support if (Byou join their developer's program. (B (BThe best option, however, may be to invest in the infrastructure -- a (Blong term relationship with a qualified contractor, or even an employee (Bwhose primary duty would be to (learn how to) do the heavy lifting on (Bbackporting and upgrading. That way, the OS itself becomes more a part (Bof the company's resources. (B (B-- (BJoel Rees <[EMAIL PROTECTED]> (Bdigitcom, inc. $B3t<02qhttp://www.ddcom.co.jp> ** (B (B___ (Bfreebsd-stable@freebsd.org mailing list (Bhttp://lists.freebsd.org/mailman/listinfo/freebsd-stable (BTo unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: > Also try defining PREEMPTION in your kernel on 5.x and above (if you > are running i386 or amd64). There have been very occasional reports > of panics with this option enabled (although I use it everywhere and > have not seen problems on my heavily loaded machines), but interactive > response should be much better. I now did this on 5.4-STABLE and I cannot observe any difference. The lags still happen in the same way. The only difference seems to be that with PREEMPTION, at and shortly after boot, response seems to be actually worse and from harddisk noise it doesn't seem to load stuff in one go but in "chunks" (at least that's how it sounds). That normalizes after a while, though. Weird. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
On Mon, 23 May 2005 23:08:18 +0200 "Simon L. Nielsen" <[EMAIL PROTECTED]> wrote: > On 2005.05.23 16:51:18 -0400, Mike Jakubik wrote: > > On Mon, May 23, 2005 3:42 pm, Colin Percival said: > > > > > http://www.freebsd.org/security/ > > > > > > In addition to the material there (which is concerned with existing > > > releases), FreeBSD 5.x is expected to be supported until late 2007 > > > (FreeBSD 5.5 plus two > > > years), and FreeBSD 6.x will probably be supported until early 2009 (the > > > last FreeBSD 6.x release plus two years). > > > > Thanks for the info guys. Does this "security support" also mean that > > current ports will be compatible with the release? > > No, there are no guarantees about that. The ports/ people generally > try to make things work with older releases, but there are no > gurantees there. It's simply too much work to make such guarantees, > and this is after all an volunteer project (for most parts anyway). Not only work, but also a lack of resources; for example I just received a report from a 4.11 user regarding of of my ports that I'm unable to reproduce on my 5-STABLE and I don't have a 4.11 machine. In this case I strongly suspect a local problem, but if it is not I'll be forced to install a 4.11. Of course, is impossible to do this for all (supported branches x supported platforms), hence the "official" statement from http://www.freebsd.org/ports/. Before each release we have a "ports freeze" period when (almost) no update to the ports is made but our time is dedicated to make sure our ports work on that release. -- IOnut Unregistered ;) FreeBSD "user" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
On Mon, May 23, 2005 5:08 pm, Simon L. Nielsen said: > On 2005.05.23 16:51:18 -0400, Mike Jakubik wrote: >> >> Thanks for the info guys. Does this "security support" also mean that >> current ports will be compatible with the release? > > No, there are no guarantees about that. The ports/ people generally > try to make things work with older releases, but there are no gurantees > there. It's simply too much work to make such guarantees, and this is > after all an volunteer project (for most parts anyway). See also > http://www.freebsd.org/ports/ for the "official" statement. Right, i didnt think so. Debian is a volunteer project too, and their packaging system supports all of their branches. I guess i should look into rolling my own packages, to be sure. And yes, i realize that we just dont have an infrastructure for something like this. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Mon, May 23, 2005 at 02:31:55PM -0700, Kris Kennaway wrote: > On Mon, May 23, 2005 at 11:21:13PM +0200, Matthias Buelow wrote: > > Kris Kennaway wrote: > > > > > One thing that probably confuses and misleads a lot of people is when > > > they build world or a kernel and notice that it's taking much longer > > > than it did under 4.x, so they assume this means that 5.x is slower > > > than 4.x. It doesn't. What it means is that 5.x and 4.x have > > > different C compilers, and gcc 3.x is much slower at compiling code > > > than gcc 2.x. You have to be very careful to draw conclusions based > > > on subjective assessments like this. > > > > Another thing might be that interactive response time seems to be worse. > > While I (or rather ports) unpack the firefox/thunderbird source, the > > machine is pretty much bogged down (mouse cursor jumps around, audio > > stutters...). Haven't seen that on FreeBSD since the 386 days. > > I don't run FreeBSD on my desktop machines so I haven't seen this > myself. One obvious guess is that it's due to VFS being under Giant, > which causes lots of contention with other subsystems that also > require Giant, and therefore introduces latency. If so, you'd see a > substantial performance improvement on 6.0 with debug.mpsafevfs=1. > This option isn't yet ready for production use (especially on SMP > machines) since it still contains bugs, but it would be interesting if > someone who sees this problem could test it on 6.0. Also try defining PREEMPTION in your kernel on 5.x and above (if you are running i386 or amd64). There have been very occasional reports of panics with this option enabled (although I use it everywhere and have not seen problems on my heavily loaded machines), but interactive response should be much better. Kris pgpBVBIMYZ4Kx.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Mon, May 23, 2005 at 11:21:13PM +0200, Matthias Buelow wrote: > Kris Kennaway wrote: > > > One thing that probably confuses and misleads a lot of people is when > > they build world or a kernel and notice that it's taking much longer > > than it did under 4.x, so they assume this means that 5.x is slower > > than 4.x. It doesn't. What it means is that 5.x and 4.x have > > different C compilers, and gcc 3.x is much slower at compiling code > > than gcc 2.x. You have to be very careful to draw conclusions based > > on subjective assessments like this. > > Another thing might be that interactive response time seems to be worse. > While I (or rather ports) unpack the firefox/thunderbird source, the > machine is pretty much bogged down (mouse cursor jumps around, audio > stutters...). Haven't seen that on FreeBSD since the 386 days. I don't run FreeBSD on my desktop machines so I haven't seen this myself. One obvious guess is that it's due to VFS being under Giant, which causes lots of contention with other subsystems that also require Giant, and therefore introduces latency. If so, you'd see a substantial performance improvement on 6.0 with debug.mpsafevfs=1. This option isn't yet ready for production use (especially on SMP machines) since it still contains bugs, but it would be interesting if someone who sees this problem could test it on 6.0. Any takers? Kris pgpGHmDcm6dNl.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: > One thing that probably confuses and misleads a lot of people is when > they build world or a kernel and notice that it's taking much longer > than it did under 4.x, so they assume this means that 5.x is slower > than 4.x. It doesn't. What it means is that 5.x and 4.x have > different C compilers, and gcc 3.x is much slower at compiling code > than gcc 2.x. You have to be very careful to draw conclusions based > on subjective assessments like this. Another thing might be that interactive response time seems to be worse. While I (or rather ports) unpack the firefox/thunderbird source, the machine is pretty much bogged down (mouse cursor jumps around, audio stutters...). Haven't seen that on FreeBSD since the 386 days. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Mon, May 23, 2005 at 05:00:13PM -0400, Mike Jakubik wrote: > On Mon, May 23, 2005 3:51 pm, Kris Kennaway said: > > > The common wisdom has been that FreeBSD 4.11 is faster than 5.4 on > > single processor systems. Imagine my surprise when I went and actually > > benchmarked this on the package build machines, and found that 5.4 > > outperforms 4.11 by at least 10% when performing identical workloads on > > identical UP hardware :-) > > > > Stay tuned for more details... > > To be honest, i have not (yet) done any specific benchmarks for my > application, but overall, last time i used 4.x, it seemed more snappy. > But, this is good to hear :) One thing that probably confuses and misleads a lot of people is when they build world or a kernel and notice that it's taking much longer than it did under 4.x, so they assume this means that 5.x is slower than 4.x. It doesn't. What it means is that 5.x and 4.x have different C compilers, and gcc 3.x is much slower at compiling code than gcc 2.x. You have to be very careful to draw conclusions based on subjective assessments like this. Kris pgp9W2pTiA38u.pgp Description: PGP signature
Re: Lifetime of FreeBSD branches
On 2005.05.23 16:51:18 -0400, Mike Jakubik wrote: > On Mon, May 23, 2005 3:42 pm, Colin Percival said: > > > http://www.freebsd.org/security/ > > > > In addition to the material there (which is concerned with existing > > releases), FreeBSD 5.x is expected to be supported until late 2007 > > (FreeBSD 5.5 plus two > > years), and FreeBSD 6.x will probably be supported until early 2009 (the > > last FreeBSD 6.x release plus two years). > > Thanks for the info guys. Does this "security support" also mean that > current ports will be compatible with the release? No, there are no guarantees about that. The ports/ people generally try to make things work with older releases, but there are no gurantees there. It's simply too much work to make such guarantees, and this is after all an volunteer project (for most parts anyway). See also http://www.freebsd.org/ports/ for the "official" statement. > I'm surprised to see that 4.11 will be supported longer than > RELENG_5. That is just the current status, RELENG_5 is almost certain to be supported longer than RELENG_4, but exactly how long isn't determined until FreeBSD 5.5, but Colin's timeline applies and is probably a very good estimate, since he is also one of the people that will actually work on supporting it :-). > Guess my best bet would be to wait for 6.x. WRT. to security support there wouldn't be a difference. > Now, does anyone know if a make buildworld/kernel update will be possible > for 5.x to 6.x ? I'm assuming that they are similar enough for this to be > possible. It's a much smaller step than 4.X -> 5.X was, so it's much more likely that a the upgrade path will be much less painful, than 4.X -> 5.X was/is. -- Simon L. Nielsen pgpKeXAoTgti8.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Mon, May 23, 2005 3:51 pm, Kris Kennaway said: > The common wisdom has been that FreeBSD 4.11 is faster than 5.4 on > single processor systems. Imagine my surprise when I went and actually > benchmarked this on the package build machines, and found that 5.4 > outperforms 4.11 by at least 10% when performing identical workloads on > identical UP hardware :-) > > Stay tuned for more details... To be honest, i have not (yet) done any specific benchmarks for my application, but overall, last time i used 4.x, it seemed more snappy. But, this is good to hear :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
On Mon, May 23, 2005 3:42 pm, Colin Percival said: > http://www.freebsd.org/security/ > > > In addition to the material there (which is concerned with existing > releases), FreeBSD 5.x is expected to be supported until late 2007 > (FreeBSD 5.5 plus two > years), and FreeBSD 6.x will probably be supported until early 2009 (the > last FreeBSD 6.x release plus two years). Thanks for the info guys. Does this "security support" also mean that current ports will be compatible with the release? I'm surprised to see that 4.11 will be supported longer than RELENG_5. Guess my best bet would be to wait for 6.x. Now, does anyone know if a make buildworld/kernel update will be possible for 5.x to 6.x ? I'm assuming that they are similar enough for this to be possible. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Mon, May 23, 2005 at 03:21:32PM -0400, Mike Jakubik wrote: > Could someone point me to a resource that outlines the expected supported > lifetime of all the branches? Can't find anything concrete on the webpage. > > I'm developing a product, which i hope will run on FreeBSD. However the > rapid development of 5, and now 6 arriving out in a few months has me > worried if FreeBSD will be the right choice short and long term. I have > even considered using 4.11 for its stability and speed on single processor > systems, but I'm worried that some ports/hw will not be supported. The common wisdom has been that FreeBSD 4.11 is faster than 5.4 on single processor systems. Imagine my surprise when I went and actually benchmarked this on the package build machines, and found that 5.4 outperforms 4.11 by at least 10% when performing identical workloads on identical UP hardware :-) Stay tuned for more details... Kris pgpMYs5NqAa8M.pgp Description: PGP signature
Re: Lifetime of FreeBSD branches
Mike Jakubik wrote: > Could someone point me to a resource that outlines the expected supported > lifetime of all the branches? Can't find anything concrete on the webpage. http://www.freebsd.org/security/ In addition to the material there (which is concerned with existing releases), FreeBSD 5.x is expected to be supported until late 2007 (FreeBSD 5.5 plus two years), and FreeBSD 6.x will probably be supported until early 2009 (the last FreeBSD 6.x release plus two years). Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lifetime of FreeBSD branches
On Mon, May 23, 2005 at 03:21:32PM -0400, Mike Jakubik wrote: > Could someone point me to a resource that outlines the expected supported > lifetime of all the branches? Can't find anything concrete on the webpage. http://www.freebsd.org/security/ - It's listed about 1/3 of the way down the page in a table. -- WXS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Lifetime of FreeBSD branches
Could someone point me to a resource that outlines the expected supported lifetime of all the branches? Can't find anything concrete on the webpage. I'm developing a product, which i hope will run on FreeBSD. However the rapid development of 5, and now 6 arriving out in a few months has me worried if FreeBSD will be the right choice short and long term. I have even considered using 4.11 for its stability and speed on single processor systems, but I'm worried that some ports/hw will not be supported. The recent amount of problems with 5 has me a little discouraged too, and even considering Linux as an alternative. Hopefully that wont be the case, but a clear outline of whats to come would be very helpful in the decision making. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
