Contributed by jose on from the no-locks-are-better-than-deadlocks dept.
"Jeremy Andrews over from KernelTrap has an interesting synopsis regarding the current state of SMP support in OpenBSD."SMP on OpenBSD is many peoples' dream. A project like the Spinlocks project seems to be dormant (I recently mailed them to see if they could give any updates). The OpenBSD-smp list is 99% NOT developer traffic but instead wistful thinking. So, give the Kerneltrap piece a good read and exhale, because holding your breath for OpenBSD SMP is not good.
(Comments are closed)
By Anonymous Coward () on
By michael () on
By T () corgimax@hotmail.com on mailto:corgimax@hotmail.com
Comments
By Anonymous Coward () on
Comments
By zil0g () on
By Anonymous Coward () on
SMP is big, it lets OpenBSD play with a lot of real application tasks.
By Teknoenie () teknoenie@site-fx.net on http://www.site-fx.net
Comments
By Anonymous Coward () on
The word that comes to my mind is HyperThreading. Multiple chips on a die are coming too. SMP is the coming thing whether Theo likes it or not.
Comments
By grey () on http://www.cansecwest.com
It's not just Intel either. I'm sure AMD will look towards some form of HT tech if x86-64 generates them enough revenue to keep fighting (here's hoping. Preliminary reports from a friend @ RSA who has been using the Opterons says they're awesome [and he's been using Intaniums for ~3 years without any kind of lasting impression] to quote: "Compiling looks like ls flying by!"). Meanwhile, IBM is making HT/multicore cpu's in their power series and will likely extend that into the PPC970 derivates we're bound to see in Mac hardware by next year. Even HP and Sun I think I recall reading of having multicore+/htish offerings in the future [though Sun is continuing to be a dick to OpenBSD it seems, so I'm not holding my breath for niceness when they push USIV and US5 architectures].
MP support for various architectures has been on art's list for a long time (it would be nice to see a changelog of that as an aside). It is going to happen, someday. But, this is OpenBSD - light speed is not what they do (or what the users want).
But look at what you've likely heard before:
ELF support for x86 is coming soon, now that 3.3 has been sent to get pressed. (weeks from now in all likelihood). As someone else mentioned, this could aid in getting us up to date with gcc (we're still on 2.95). Then in turn, Getting to a newer GCC will enable us to support x86-64 natively (2.95 does not offer support from what I've heard). Where does SMP fit into that? Well, it doesn't - but groundwork is being laid for some more fundamental changes (there's already tons of other stuff going on related just to ELF support, art's been cranking on a different debugger and much more), which will in turn allow for more dramatic events (like a new architecture) to happen. I'm sure that we can expect the same with SMP.
The information is out there, and it's already pretty clear in what direction certain things are headed. As I see it, ELF and x86-64 support are going to be bigger items than SMP. On the other hand, after things like that are in... I can't really see anything [for _now_] that would be a bigger neat new cpu-oriented feature to work towards (well, maybe supporting PPC970's for future apples if that's the direction taken).
Another way to break it down is to look at a wishlist of sorts (note this is maybe more mine, not a developer wishlist) and then rank things as far as likelihood:
ELF for x86: likely (imminent actually, private work has been cranking along for a while)
Newer gcc: likely, though this might cause some headaches with all the propolice work we've done (although propolice has already worked with gcc 3.2 from other reports, we'll see how many bumps there are).
x86-64 support: (Just look at Theo's comments here, even he's excited about this architecture) extremely likely - but certain things need to happen first.
PPC970 support: well, once Apple releases hardware, we'll see if that's what happens and when - time frame unknown (next year?).
SMP support: someday - I think everything else might take precidence.
OpenCM: pretty unlikely (it's a pig by all accounts), it will likely need to have major improvements on its own before we see it.
TenDRA: wouldn't it be nice to dump as much GNU as possible? Unfortunately, others tell me that I am hitting the crack pipe too hard (and they're very likely right in this case). It would still be neat, but this is ages out if ever - it needs to be functionally equivalent to gcc for all our architectures, and we'd have to deal with propolice and tendra intregration, and on and on.
There's a -lot- more out there too, but those are just some bigger things that have been popular on deadly in the past half year. You'll notice that some are recurring themes (like SMP) whereas others are pretty new (x86-64). I'm hoping that at Theo's talk at CanSecWest (SIGN UP AT www.cansecwest.com ) next week he will take a pretty long look, not just at the cool stuff from 3.3 that -current users have been appreciating, not just at things that will be nailed by 3.4, but even beyond. Of course, with any kind of future looking (even if you're the head of the project) you can't really state anything with certainty, or give hard and fast dates, but I wonder what else might be up his (and others') sleeve.
Comments
By Anonymous Coward () on
By Anonymous Coward () on
SMT is the correct definition for that technology.
Also, the POWER4 from IBM does not feature SMT but CMP. It has multiples cores on one die, and multiple dies on one module (MCM).
SMT was implemented in some of IBM's *Star CPUs (Northstar etc.), which were a POWER3 implementation IIRC.
Comments
By grey () on
More information (and likely more accurate) on future CPU roadmaps can be found here:
http://www.realworldtech.com/page.cfm?AID=RWT012603224711
And I do realize that currently IBM has only had multicore implementations in their power series, but if you refer to the article below you'll see that IBM is also working on SMT -and- multicore support in future Power hardware releases. Albeit, I don't think we'll see -that- in a consumer machine that OpenBSD would be likely to support anytime soon (at all?). Article is here:
http://www.siliconstrategies.com/story/OEG20030224S0052
With regards to the other poster mentioning lack of ACPI support, sorry I'm not omniscient, and I can't (and didn't) list every neat feature that could or should be added. Just a question though, does x86-64 really -require- ACPI?
By Anonymous Coward () on
By Alejandro Belluscio () baldusi@guesswho.com on mailto:baldusi@guesswho.com
By grey () on http://www.openbsd.org/crypto.html
Depending on one's needs and what one buys - various supported hardware cryptographic accellerators are already A. working and B. more economical for this task.
But, they're also dependant on the cipher. While AES chips have been trickling into the market for a while now - I doubt we'll ever see blowfish or twofish implemented in hardware (by the same token, *fish is pretty fast in software, then again AES had that as a design goal as well), so possibly SMP support as a generic crypto offload would be effective. But really, crypto support I think won't really benefit much from SMP, when a crypto board/chip could suffice more economically in many cases. SMP is not a panacea for throughput - however, it is a more generic way of making things speed up in hardware, when a specific hardware offering might not be available.
By Henning () henning@openbsd.org on mailto:henning@openbsd.org
By Anonymous Coward () on
By Anonymous Coward () on
Comments
By Nuintari () on
But I want it! Gimme! Gimme! Gimme!
Comments
By Anonymous Coward () on
Comments
By Nuintari () on
Comments
By Beop () on
Comments
By Anonymous Coward () on
By Nuintari () on
Dynamic web servers can be cpu intense, but to get them cpu intnse, your probably either a really bad coder, writing everything in interpreted languages and making your scripts way too long, and/or your saturating the network, thereby, cpu time is sitting idle waiting for stuff to go through.
Servers don't need much speed, they need bus bandwidth, network bandwidth, and memory, and of course, disk space.
Now, workstations, for serious crunchwork, yeah, I would want a sun e450 for my workstation, quad cpu nightmare. But I still don't need it. ALmost no one ever puts dual and quag systems to good use.
Sorry, not spellchecking that.
Comments
By Beop () on
Comments
By Anonymous Coward () on
By Stefan () on
... and I forsee the time of reckoning is upon us.*
... well, if I'm not mistaken it is one
of the advantages of OpenBSD that it runs on
rather modest hardware - and a lot of people really
appreciate that - don't have to run to the store
when another kind of "multi-matrix-psionic-enhanced"-whatever
CPU comes out.
cheers
stefan
* sorry, couldn't resist.
By Anonymous Coward () on
By Cyrus Yunker () cyrus@80d.org on http://80d.org
From: Niklas Hallqvist
To: smp
Subject: Status
Date: Fri, 21 Mar 2003 14:37:24 +0100
...
* All the working code there is, is in the SMP branch. It is only
i386-specific parts, no machine-independent parts have been worked
upon. The code manages to detect and spinup a 2nd processor, but
not let it do any useful work.
...
I'm guessing that most developers see this project as much to large of a bite to swallow, and nobody really knows where to start, since the code affects so many subsystems. People realize the work is tedious and are worried about breaking things, exposing the system to security flaws, etc.
Rather than attacking the whole project (blank page syndrome), start by getting the other processor fired up and give it little jobs, integrating into only specific parts of the system that people can manage.
I'd suggest, for starters, just using additional processors to offload crypto work, manage filesystems, or do packet mangling. Rather than trying to integrate spinlocks and get another processor into every bit of work that's going on in a typical system, just make it availible for specific jobs, and speedup those.
Ideas:
Speedup encrypted filesystem operations
ditto for encrypted swap
let mod_gzip use the processor for web traffic
key generation
bzip2 module that could use the additional CPU
Perhaps some sort of module system could be built, and the additional processor management code could be designed to manage only those plugins. A separate "thread namespace" could exist on the additional processor, almost completely separated from the regular system kernel and userland processes. System and userland processes could communicate with these modules via some sort of communication layer, allowing work to be offloaded to the, perhaps at times, very unbusy silicon.
It's not full use of the system potential, but you'd have your OpenBSD security, and you'd be farther ahead than you are now.
I'm not an OpenBSD developer and would be happy to hear about the faults with this idea. It's just something that popped into my head, and I hadn't seen it elsewhere, so I thought I'd put it out there to you all.
Let the other work (fully MP enabling OpenBSD) be ported over as people become interested and want to spend the time going through the tedious work.
Comments
By Christian Gruber () cgruber@israfil.net on http://www.israfil.net
By Firdarrig () on
The idea about offloading smaller tasks to a second processor is neat, though, and kind of a unique angle: you can do that on Solaris using pbind, but it has to be manually initiated by the admin rather than automatically done by the OS. That could be super-useful on an IDS sensor node: dedicate one processor to receiving and queuing packets (including reassembly) and the other to matching them against a signature database and sending the results upstream to a manager. Hmm...
Comments
By Anonymous Coward () on
By Anonymous Coward () on
"Sync the SMP branch to 3.3."
SMP to come ?
Comments
By zil0g () on
By Ash'aman () on
I'd much rather developers spent time doing all the great things that they've done like systrace, pf, propolice integration, privilege separation, chroot apache, spamd, minimising setuid binaries, hardware crypto support, than any of this smp garbage. It's so much work for so little reward.
I'd much rather developers spent time on such things as improving the scsi subsystem, hardware support for onstream tape drives & some fibre channel adapters, porting to new sparc and amd systems and working on things like UFS2, documentation, and licensing.
If OpenBSD had a team even half the size of say the team working on the linux kernel with the same injections of cash that Linux gets from IBM, Oracle, RedHat, etc., then I think that expectations of SMP in OpenBSD would be reasonable, but the fact is they don't. Even with DARPA funding, the priorities of the project should come first. That's why I use it, and that's why SMP wonks should use another OS if it's so important to them.
By Iain () on mailto:ikyte(at)yahoo(dot)com
To do this we need to continue to assemble the re-write team. Process and scheduling will need to be done. First is any one with the info on documents, white papers, thesis, ect., should assemble them on the SMP document page.
Next we should do a Kernel Map. This will help isolate the locations to put the locks and add ons needed. On the side it will help with Code Walk Throughs and getting new Kernel Developers started.
After the above the team could plan the strategy, who does what, when to test. When a prelinary version is ready we move to the larger test groups. After which it is then submitted for Code Review.
If the core team accepts we then stamp OpenBSD version X.Y now has SMP.
Question, Do we want to support one or two kernels. That is one kernel with SMP for Intel or two, one with SMP and one without?
Iain
Comments
By Anonymous Coward () on
By Kyle Korndoerfer () on
I would like to see SMP for a simple reason: I can replace my aging P1-233MMX machine for free with a 2x200 Pentium Pro server from my employeer that has run it's course and is being decomishened. I would prefer to run OpenBSD for the reasons stated above and would prefer to have both CPU's being used.
I know the responses will be to just setup another box, but space and money are both issues. OpenBSD runs great on older hardware that is cheap to find and use.