Re: SMP changes and breaking kld object module compatibility
Hi, I said: > I am guessing that little of the above will be MFC'd into 4.0. So the issue > of the current SMP patch set should be based on its merits alone. I would > agree that they in themselves are worthy of MFCing. Lets just not kid Mike Smith replied: > Steve Passe actually argued quite eloquently against his own decision; > the "real work" that actually depends heavily on this foundation is > almost certainly never going to come back to the 4.x branch. Since these > changes don't actually bring any real improvements in and of themselves, > there's little point in merging them for their own sake. I based my opinion on the belief that they did indeed bring in a performance benefit (I think I remember the value of 7% being tossed around). I took those numbers on face value, if correct I stand by my "decision". I didn't run any tests with code pre-Matts-changes, so I can't confirm or deny them. My "decision" is also based purely on the technical merits of the exercise, I have to admit I never thought much about the issues of stable ABI. Coming from where I do, I readily admit I am a poor judge of this issue... For my post-Matts-changes tests check out: http://www.freebsd.org/~fsmp/SMP/rbenches.html -- Steve Passe | powered by [EMAIL PROTECTED] |Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP changes and breaking kld object module compatibility
Hi, >So you guys (core) choose -- do you want 4.x to reap the benefits of >further SMP development or not? If you choose no, beware that without >this base cleanup there is *NO* chance whatsoever of any further SMP >work being MFC'd to 4.x. None. Zilch. It will have diverged too >much. As the original author of the cil/cml code I can say I was glad to see that Matt had finally put it to rest. It was a desperate hack made in an attempt to pinch a little more performance out of the paradigm without dealing with the whole spl() problem set. I would have done it myself if life hadn't taken me down a path where I have too little time for these things... I've been playing with test buildworlds on my server and have concluded that we are currently kernel (big giant lock?) bound. In my tests 3 CPUs actually complete buildworld faster than 4. The major solutions to SMP in the future will come from: 1: pushdown of the BGL into the read/write routines. 2: kernel threads. 3: replacement of spl() with mutex() type protection of data regions. I am guessing that little of the above will be MFC'd into 4.0. So the issue of the current SMP patch set should be based on its merits alone. I would agree that they in themselves are worthy of MFCing. Lets just not kid ourselves about major future improvements of SMP in 4.0, the biggies I enumerate above just won't happen there. -- Steve Passe | powered by [EMAIL PROTECTED] |Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current-digest V4 #794
Hi, I need to run FreeBSD-VMWare-vnc-winblows to avoid importing actual winblows boxes to our desktops. As hub's search engine is down I wasn't able to do any preliminary research, so... What version of FreeBSD would be most appropriate to load this onto? What release of VMWare would I want to use? Any other advice greatly appreciated! tia, -- Steve Passe | powered by [EMAIL PROTECTED] |Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Subnotebook capable of running -current
Hi, >I want to purchase some kind of 'subnotebook', that has to >be as -current-compatible as possible. > >I anticipate the crowd whispering "Libretto, ... Libretto", but >I have to say, that I don't like the Libretto very much for its >crude screen resolution. > >Currently I'm tending towards the "Toshiba Portege 3010" >or the "Fujitsu LifeBook B110 Biblo". > >Any experiences with these decices? > >I'm wondering about the CD-drives connected thru a PCMCIA-Card >and FreeBSD-compatible PCMCIA-Network-Cards. I just got my toshiba portege 7020CT yesterday (it took 35 days and 3 reschedules to actually reach my front door!). Loaded 4.0-0306-SNAP and XF86-3.3.3.1 without problems (well, sorta, had to run sysinstall-XF86 config program a half dozen times b4 it worked properly...) This is the big brother to the 3010, 13.1" 1024x768 TFT display, neomagic 2200 chipset. The really nice part is that the main unit has neither floppy or CDROM, making it reasonably small for a 13" display. It comes with an external floppy and port replicator, but I opted for the optional loading dock which comes with floppy, DVDROM, and fxp0 (intel) 10/100 ethernet. So I was able to to do an NFS (ie ethernet) install with the dock network, not needing to deal with pc cards. To load packages I inserted my 3.1R CD into the DVD drive and ran /stand/sysinstall, worked great. I used defrag and fips b4 installing FreeBSD, seems to have worked OK also. I will continue to use m$$ucks for hardware setup till I get a handle on APM and friends. Now I just need some free time to help with the card-bus stuff! -- Steve Passe | powered by s...@csn.net|Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Annoying messages on startup..
Hi,
> j...@zippy-> dmesg|grep Freeing
> Freeing (NOT implemented) redirected ISA irq 11.
> Freeing (NOT implemented) redirected ISA irq 10.
> Freeing (NOT implemented) redirected ISA irq 10.
> Freeing (NOT implemented) redirected ISA irq 10.
> Freeing (NOT implemented) redirected ISA irq 9.
> Freeing (NOT implemented) redirected ISA irq 10.
>
> Can these just go away? They certainly don't tell *me* anything
> useful and if it's a feature which should be implemented then
> we ought to implement it. If it's just a harmless warning, then
> we ought to just remove it. :-)
I'm the person who put those there, and yes, they are meant to be
annoying. I was hoping that someone who already knew the insides
of motherboard chips would pick it up and fix it, but I guess not...
Essentially they refer to the fact that an APIC pin is directly
connected to a PCI INT, (theoretically) freeing up the ISA path
for another INT source on the ISA bus. I believed at the time
that this could be done by reprogramming the PCI/ISA redirection
circuit in the MB chipset, but never got around to proving it.
At the very least they could be moved to "if ( bootverbose ) ..."
Someone might also remove the:
interrupt mask = cam <- SMP: XXX
^^^
from:
trap.c: printf(" <- SMP: XXX");
I have no memory as to whether the associated comment is valid!
--
Steve Passe | powered by
s...@csn.net|Symmetric MultiProcessor FreeBSD
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
