Re: total hang when cu -l /dev/cuaa0
On Fri, Oct 03, 2003 at 11:36:29PM +0200, Bernd Walter wrote: > > > The modem coild also be something proprietary for which there is no > > > driver available. > > > > > > > When I run getty (or mgetty) on that port or when I do a cu -l /dev/cuaa0 > > > > the system freezes. > > > > > > Why do you expect anything usefull by accessing half working hardware? > > > > Well, I would expect an I/O error or no such device. Wouldn't that be > > at least a minimum one could expect? But a crash or hand? No. ^^ I believe I wanted to say 'hangup'. > > one could expect? But a crash or hand? No. Smoteihng got colbbreed drunig tpynig. ;-) > > You can't expect anything reliable from a device which is broken. > The kernel already warned you that something seems to be questionable. > In the same way you can't expect getting an IO error if someone cuts > into your computer with a chainsaw - you may get one, but nobody can > predict. A device disabled by the BIOS should not be accessible in any way by the kernel. It's not broken nor has anyone cut the devices with a chainsaw. I don't read dmesg before I try to open /dev/cuaa0. So an open on /dev/cuaa0 when sio is disabled in the BIOS should not result in a bad hangup. That's my point. > B.Walter BWCThttp://www.bwct.de -- Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: total hang when cu -l /dev/cuaa0
On Sat, Oct 04, 2003 at 10:25:48AM +0200, Christoph P. Kukulies wrote: > On Fri, Oct 03, 2003 at 11:36:29PM +0200, Bernd Walter wrote: > > You can't expect anything reliable from a device which is broken. > > The kernel already warned you that something seems to be questionable. > > In the same way you can't expect getting an IO error if someone cuts > > into your computer with a chainsaw - you may get one, but nobody can > > predict. > > A device disabled by the BIOS should not be accessible in any way > by the kernel. It's not broken nor has anyone cut the devices with a chainsaw. > I don't read dmesg before I try to open /dev/cuaa0. > > So an open on /dev/cuaa0 when sio is disabled in the BIOS should not result > in a bad hangup. That's my point. If it really is disabled then you would not have a /dev/cuaa0 to open and you would see a correct error when trying to do. The point is that the kernel sees partially disabled hardware. A device that is something between enabled and disabled cause unpredicable behavour - it's a completely undefined situation. The easiest way is to disable the device in the kernel too. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: total hang when cu -l /dev/cuaa0
On Fri, Oct 03, 2003 at 05:04:22PM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Bernd Walter <[EMAIL PROTECTED]> writes: > : You need a different driver for your PCI one - e.g. puc. > > actually, puc still uses sio/uart. puc just manages the bus > resources. So puc would not help me here, wouldn't it? Where do I find puc, btw? I don't see a device puc in /sys/i386/conf/* > > : The modem coild also be something proprietary for which there is no > : driver available. So what would be the way to go from here ? What card is supported? Or should I set out for an external modem? USB modem? > > I've helped people locally that have 'supported' pci modems that no > longer work. Causes an interrupt storm the first time they are > accessed. :-( > > Warner -- Chris Christoph P. U. Kukulies ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CMI8330 freeBSD problem
Hello Andrei, I'm now having the same problem as you deed with my ISA sound card (CMI8330). It does not work. Already I've recompiled the kernel with the following lines added to the kernel configuration file: device pcm device sbc as stated on the freeBSD.org site. If you solved your problem, please tell me how you did it. Thanks, Liviu -- K Free E-mail http://www.k.ro/ Vacante si calatorii prin http://www.romaniantourism.ro/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] : libc_r/uthread/uthread_write.c
On Mon, 29 Sep 2003, Dan Langille wrote: > > All our testing on this patch has been successful. I'm going to do a > few more tests on different hardware under 4.8-stable. > > What's the next step? Commit it? Get others to test with it first? It's already in -current. You'll have to wait for the code freeze to thaw in -stable before it goes in there. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[no subject]
I need some startup help in moving my new systems. Sure would appreciate it if I could get a pointer here on a couple of matters. My new physical location has really improved things, but my mail isn't working yet, right, and my keyboard is also going wrong. My mail has to come first, here the setup: I want to use my FreeBSD box, april, to relay mail from my Mac OS/X box, which has the address of "may". Actually, I have 4 static IPs, and I want april to allow me to send mail from anything in my domain to anywhere I want to send it. That's the only relaying I want to allow, I want to be careful and not become a spam-source. I tried to send a mail to my work, and may correctly tried to relay through april. I caught the transaction in ethereal, and it looks like april is looking at the destination of the mail, my work address, and denying it based on that. I thought it would only be using the source address to allow or disallow the relaying. Guess I'm wrong. I have all my local machine names in /etc/mail/local-host-names. What else do I have to do to get my relaying (to anywhere I want to send it, here) working? Second part, the usb. I'm running current, BTW. I have done the stuff in the kernel config, I hope: I took out the "device atkbd" line and replaced it with the ukbd line. I put in the ukbd device, rebooted. Now, it's started to recognize the keyboard, but very oddly ... it seems to recognize about 1 key a minute, and it also seems to get hung up on a signle key (recognize it as if I was leaning on the key for 30 seconds, like maybe it saw the down but not the up). I tried the line from the kbdcontrol manpage, "kbdcontrol -k /dev/kbd1 < /dev/console", that keeps on telling me that the device is busy. The usb device I'm using is the one on the motherboard of this Tyan Thunder K7X, no hub. Here's the section of my config file that applies: # usb devices device usb device uhid device udbp device ugen device uhci device ohci device ulpt device uscanner device umass device ums # tell the kernel to make the device, it's not automatic options KBD_INSTALL_CDEV # The AT keyboard device atkbd device ukbd # new syscons stuff device vga device sc device sio Thanks for the help, fellas, I sure hope this gets to you. I am reading my mail fine, at least! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] : libc_r/uthread/uthread_write.c
On 4 Oct 2003 at 10:17, Daniel Eischen wrote: > On Mon, 29 Sep 2003, Dan Langille wrote: > > > > All our testing on this patch has been successful. I'm going to do a > > few more tests on different hardware under 4.8-stable. > > > > What's the next step? Commit it? Get others to test with it first? > > It's already in -current. Thanks for that commit. > You'll have to wait for the code > freeze to thaw in -stable before it goes in there. Bugger... which means it won't be into 4.9-RELEASE. -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Hyperthreading slowdown
Hi I installed FreeBSD 4.9RC1 on P4 3GHz with hyperthreading and I see drastic slowdown when kernel with hyperthreading is booted. For example program compilation took this time: hyperthreading kernel, make -j 1 --- 1:09 hyperthreading kernel, make -j 2 --- 0:42 singlethreading kernel, make -j 1 --- 0:45 singlethreading kernel, make -j 2 --- 0:41 Compilation does very few system calls so when I compile with only one process (-j 1), it should be as fast as with singlethreading kernel. Do you have any idea why is it so slow? Mikulas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is socket buffer locking as questionable as it seems?
On Sat, 4 Oct 2003, Brian Fundakowski Feldman wrote: > I keep getting these panics on my SMP box (no backtrace or DDB or crash > dump of course, because panic() == hang to FreeBSD these days): panic: > receive: m == 0 so->so_rcv.sb_cc == 52 From what I can tell, all sorts > of socket-related calls are "MP-safe" and yet never even come close to > locking the socket buffer. From what I can tell, the easiest way for > this occur would be sbrelease() being called from somewhere that it's > supposed to, but doesn't, have sblock(). Has anyone seen these, or a > place to start looking? Maybe a way to get panics to stop hanging the > machine? TIA if anyone has some enlightenment. The system calls are marked MPSAFE in the case of the socket calls because the grabbing of Giant has been pushed down into the system call, as opposed to Giant being grabbed by the system call code itself. Giant should be held across all the relevant socket-related events -- if you find a place where it's not, send some details :-). As you observe, there is currently no socket locking in the source tree, although I'm hopeful that will be remedied in the next couple of months. The lower levels of the IP stack can be run Giant-free at this point, although my local patches to run multiple input paths in parallel runs into a panic due to insufficient locking in ip_forward() (bug report already filed with Sam). One of the conclusions from the recent developer summit was that a big focus needs to be placed on interrupt processing latency and device driver improvements so that we get the benefits of finger-grained locking. Peter's has picked up the task of doing a driver API sweep to provide better facilities for doing this. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is socket buffer locking as questionable as it seems?
On Friday 03 October 2003 10:38 pm, Brian Fundakowski Feldman wrote: > I keep getting these panics on my SMP box (no backtrace or DDB or crash > dump of course, because panic() == hang to FreeBSD these days): > panic: receive: m == 0 so->so_rcv.sb_cc == 52 > From what I can tell, all sorts of socket-related calls are "MP-safe" > and yet never even come close to locking the socket buffer. From > what I can tell, the easiest way for this occur would be sbrelease() > being called from somewhere that it's supposed to, but doesn't, have > sblock(). Has anyone seen these, or a place to start looking? Maybe > a way to get panics to stop hanging the machine? TIA if anyone has > some enlightenment. Haven't seen anything on my SMP test box. As Robert has already said sockets are still implicitly locked by Giant. You need to provide more information like what version you are running and what your system is doing when the panic occurs. FWIW panic does not hang for me so you might first try to figure out why that's occuring. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hyperthreading slowdown
On Sat, Oct 04, 2003 at 04:39:03PM +0200, Mikulas Patocka wrote: > Hi > > I installed FreeBSD 4.9RC1 on P4 3GHz with hyperthreading and I see > drastic slowdown when kernel with hyperthreading is booted. For example > program compilation took this time: > > hyperthreading kernel, make -j 1 --- 1:09 > hyperthreading kernel, make -j 2 --- 0:42 > singlethreading kernel, make -j 1 --- 0:45 > singlethreading kernel, make -j 2 --- 0:41 > > Compilation does very few system calls so when I compile with only one > process (-j 1), it should be as fast as with singlethreading kernel. Do > you have any idea why is it so slow? Do you realise that hyperthreading != a secret extra CPU in your system? Kris pgp0.pgp Description: PGP signature
Re: Hyperthreading slowdown
Kris Kennaway wrote: On Sat, Oct 04, 2003 at 04:39:03PM +0200, Mikulas Patocka wrote: I installed FreeBSD 4.9RC1 on P4 3GHz with hyperthreading and I see drastic slowdown when kernel with hyperthreading is booted. For example program compilation took this time: hyperthreading kernel, make -j 1 --- 1:09 hyperthreading kernel, make -j 2 --- 0:42 singlethreading kernel, make -j 1 --- 0:45 singlethreading kernel, make -j 2 --- 0:41 Compilation does very few system calls so when I compile with only one process (-j 1), it should be as fast as with singlethreading kernel. Do you have any idea why is it so slow? Do you realise that hyperthreading != a secret extra CPU in your system? Kris I didn't see anywhere in the message where he implied that. To me, the interesting thing is that there is such a larger difference between the compile time for -j1 and -j2 when using hyperthreading as compared to the difference between -j1 and -j2 for a single threaded kernel. It's over a 50% slowdown. Richard Coleman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hyperthreading slowdown
On Sat, Oct 04, 2003 at 03:20:03PM -0400, Richard Coleman wrote: > Kris Kennaway wrote: > >On Sat, Oct 04, 2003 at 04:39:03PM +0200, Mikulas Patocka wrote: > >>I installed FreeBSD 4.9RC1 on P4 3GHz with hyperthreading and I see > >>drastic slowdown when kernel with hyperthreading is booted. For example > >>program compilation took this time: > >> > >>hyperthreading kernel, make -j 1 --- 1:09 > >>hyperthreading kernel, make -j 2 --- 0:42 > >>singlethreading kernel, make -j 1 --- 0:45 > >>singlethreading kernel, make -j 2 --- 0:41 > >> > >>Compilation does very few system calls so when I compile with only one > >>process (-j 1), it should be as fast as with singlethreading kernel. Do > >>you have any idea why is it so slow? > > > >Do you realise that hyperthreading != a secret extra CPU in your system? > > > >Kris > > I didn't see anywhere in the message where he implied that. To me, the > interesting thing is that there is such a larger difference between the > compile time for -j1 and -j2 when using hyperthreading as compared to > the difference between -j1 and -j2 for a single threaded kernel. It's > over a 50% slowdown. Yes, that's because (as discussed in the archives) the kernel treats it like an extra, completely decoupled physical CPU and schedules processes on it without further consideration. This is presumably the cause of the slowdown, because it's only efficient to use the virtual CPU under certain workload patterns. HTT is not magic performance beans. Kris pgp0.pgp Description: PGP signature
Re: Hyperthreading slowdown
Kris Kennaway wrote: On Sat, Oct 04, 2003 at 03:20:03PM -0400, Richard Coleman wrote: Kris Kennaway wrote: On Sat, Oct 04, 2003 at 04:39:03PM +0200, Mikulas Patocka wrote: I installed FreeBSD 4.9RC1 on P4 3GHz with hyperthreading and I see drastic slowdown when kernel with hyperthreading is booted. For example program compilation took this time: hyperthreading kernel, make -j 1 --- 1:09 hyperthreading kernel, make -j 2 --- 0:42 singlethreading kernel, make -j 1 --- 0:45 singlethreading kernel, make -j 2 --- 0:41 Compilation does very few system calls so when I compile with only one process (-j 1), it should be as fast as with singlethreading kernel. Do you have any idea why is it so slow? Do you realise that hyperthreading != a secret extra CPU in your system? Kris I didn't see anywhere in the message where he implied that. To me, the interesting thing is that there is such a larger difference between the compile time for -j1 and -j2 when using hyperthreading as compared to the difference between -j1 and -j2 for a single threaded kernel. It's over a 50% slowdown. Yes, that's because (as discussed in the archives) the kernel treats it like an extra, completely decoupled physical CPU and schedules processes on it without further consideration. This is presumably the cause of the slowdown, because it's only efficient to use the virtual CPU under certain workload patterns. HTT is not magic performance beans. Kris Sigh. No one is claiming HTT is magic performance beans. The 50% slowdown I'm talking about is between -j1 and -j2 BOTH ARE WHICH ARE USING HTT. It's just an interesting observation. That's all. Richard Coleman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hyperthreading slowdown
In message <[EMAIL PROTECTED]>, Kris Kennaway writes: >Yes, that's because (as discussed in the archives) the kernel treats >it like an extra, completely decoupled physical CPU and schedules >processes on it without further consideration. This is presumably the >cause of the slowdown, because it's only efficient to use the virtual >CPU under certain workload patterns. HTT is not magic performance >beans. Try also setting the sysctl variable "machdep.cpu_idle_hlt" to 1, as it doesn't help to have the idle logical CPUs spinning. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is socket buffer locking as questionable as it seems?
Sam Leffler <[EMAIL PROTECTED]> wrote: > On Friday 03 October 2003 10:38 pm, Brian Fundakowski Feldman wrote: > > I keep getting these panics on my SMP box (no backtrace or DDB or crash > > dump of course, because panic() == hang to FreeBSD these days): > > panic: receive: m == 0 so->so_rcv.sb_cc == 52 > > From what I can tell, all sorts of socket-related calls are "MP-safe" > > and yet never even come close to locking the socket buffer. From > > what I can tell, the easiest way for this occur would be sbrelease() > > being called from somewhere that it's supposed to, but doesn't, have > > sblock(). Has anyone seen these, or a place to start looking? Maybe > > a way to get panics to stop hanging the machine? TIA if anyone has > > some enlightenment. > > Haven't seen anything on my SMP test box. As Robert has already said sockets > are still implicitly locked by Giant. You need to provide more information > like what version you are running and what your system is doing when the > panic occurs. > > FWIW panic does not hang for me so you might first try to figure out why > that's occuring. I turned off sync on panic so maybe I'll be okay now. That never, ever, worked for me starting a couple years ago and I forgot I had it disabled locally. I see it immediately on boot and I couldn't tell you why; this is a NAT box, and a million other things. I'm running the most current current I can possibly run, of course. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Changing the NAT IP on demand?
I'm considering options for a new project, and I think I've discovered what I think is the best idea, but I don't think current software supports the config. I'd like to get some confirmation, and comments on if it would be hard to implement. Consider: ISP #1---\ \ FreeBSD BoxLAN / ISP #2---/ In this case the LAN would be 1918 space, the two ISP's would each provide a public IP for the FreeBSD box. Now, NAT would be required. What I want to do is write an external application to decide the performance of ISP #1 and ISP#2, and somehow tell NAT which outside address to use. That, by itself, is not hard. Here's the trick. I want the switch to be seamless. That is, if NAT is translating to ISP #1 and the application says switch to #2 the existing translations to #1 (until they go away naturally) should be kept, while new ones go to #2. The only ways I know to change the outside address seem to tear down all existing connections. Is it possible to make this work today? Would it be hard to fix if it doesn't work today? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is socket buffer locking as questionable as it seems?
On Saturday 04 October 2003 11:39 am, Sam Leffler wrote: > On Friday 03 October 2003 10:38 pm, Brian Fundakowski Feldman wrote: > > I keep getting these panics on my SMP box (no backtrace or DDB or > > crash dump of course, because panic() == hang to FreeBSD these days): > > panic: receive: m == 0 so->so_rcv.sb_cc == 52 > > From what I can tell, all sorts of socket-related calls are "MP-safe" > > and yet never even come close to locking the socket buffer. From > > what I can tell, the easiest way for this occur would be sbrelease() > > being called from somewhere that it's supposed to, but doesn't, have > > sblock(). Has anyone seen these, or a place to start looking? Maybe > > a way to get panics to stop hanging the machine? TIA if anyone has > > some enlightenment. > > Haven't seen anything on my SMP test box. As Robert has already said > sockets are still implicitly locked by Giant. You need to provide more > information like what version you are running and what your system is > doing when the panic occurs. > > FWIW panic does not hang for me so you might first try to figure out > why that's occuring. Is this one of the areas you are planning to get to, Sam? -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hyperthreading slowdown
On Sat, Oct 04, 2003 at 05:54:45PM -0400, Richard Coleman wrote: > hyperthreading kernel, make -j 1 --- 1:09 > hyperthreading kernel, make -j 2 --- 0:42 > singlethreading kernel, make -j 1 --- 0:45 > singlethreading kernel, make -j 2 --- 0:41 [snip] > >Yes, that's because (as discussed in the archives) the kernel treats > >it like an extra, completely decoupled physical CPU and schedules > >processes on it without further consideration. This is presumably the > >cause of the slowdown, because it's only efficient to use the virtual > >CPU under certain workload patterns. HTT is not magic performance > >beans. > > Sigh. No one is claiming HTT is magic performance beans. The 50% > slowdown I'm talking about is between -j1 and -j2 BOTH ARE WHICH ARE > USING HTT. > It's just an interesting observation. That's all. Yeah, that's precisely what Kris said :-) When you have one processes hitting either one of two CPU's, that one CPU is going to get used to the fullest. When you are splitting the processes over two CPU's extra time needs to be taken for the extra scheduling and other extra work. The increase here is significant, but not unexpected :-) Now, if you had two seperate processes fighting for CPU time, you'd see a performance increase: Try running 'make -j 1' twice, on two different kernel configs files who's contents are the same. First try it without hyperthreading and then try it with hyperthreading. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hyperthreading slowdown
Richard Coleman wrote: Kris Kennaway wrote: On Sat, Oct 04, 2003 at 03:20:03PM -0400, Richard Coleman wrote: Kris Kennaway wrote: On Sat, Oct 04, 2003 at 04:39:03PM +0200, Mikulas Patocka wrote: I installed FreeBSD 4.9RC1 on P4 3GHz with hyperthreading and I see drastic slowdown when kernel with hyperthreading is booted. For example program compilation took this time: hyperthreading kernel, make -j 1 --- 1:09 hyperthreading kernel, make -j 2 --- 0:42 singlethreading kernel, make -j 1 --- 0:45 singlethreading kernel, make -j 2 --- 0:41 Compilation does very few system calls so when I compile with only one process (-j 1), it should be as fast as with singlethreading kernel. Do you have any idea why is it so slow? Do you realise that hyperthreading != a secret extra CPU in your system? Kris I didn't see anywhere in the message where he implied that. To me, the interesting thing is that there is such a larger difference between the compile time for -j1 and -j2 when using hyperthreading as compared to the difference between -j1 and -j2 for a single threaded kernel. It's over a 50% slowdown. Yes, that's because (as discussed in the archives) the kernel treats it like an extra, completely decoupled physical CPU and schedules processes on it without further consideration. This is presumably the cause of the slowdown, because it's only efficient to use the virtual CPU under certain workload patterns. HTT is not magic performance beans. Kris Sigh. No one is claiming HTT is magic performance beans. The 50% slowdown I'm talking about is between -j1 and -j2 BOTH ARE WHICH ARE USING HTT. It's just an interesting observation. That's all. It's not interresting. It is to be expected. The only gains one could exepect are in the case where sufficently differrent execution units of the CPU would be used. Like for example doing floating point vers. integer calculations. But exen then Amdahl will bite you by the incurrend synchronisation verhead anyway.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hyperthreading slowdown
> In message <[EMAIL PROTECTED]>, Kris Kennaway writes: > >Yes, that's because (as discussed in the archives) the kernel treats > >it like an extra, completely decoupled physical CPU and schedules > >processes on it without further consideration. This is presumably the > >cause of the slowdown, because it's only efficient to use the virtual > >CPU under certain workload patterns. HTT is not magic performance > >beans. > > Try also setting the sysctl variable "machdep.cpu_idle_hlt" to 1, as > it doesn't help to have the idle logical CPUs spinning. I did and it solved the problem (-j1 is as fast on hyperthreading kernel as on singlethreading kernel). It should be default setting on hyperthreading system (or at least there should be comment around option HTT that people must set it), because otherwise performance is really terrible --- the idle thread is spinning, taking half of the CPU. Mikulas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
