Re: Random x86-64 seg-fault finally fixed
:How would this be different than jail(8)? : :not understanding the 'without virtualization' part - :I know some form of HW virt a-la kvm has been discussed a few times - : :do you mean like segmenting the 'machine' or somesuch? Jail has no ability to segment kernel resources. It is really nothing more than a glorified chroot. The idea here is to have actual separate copies of the kernel running in each partition. -Matt Matthew Dillon dil...@backplane.com
Re: Random x86-64 seg-fault finally fixed
On Sun, Dec 26, 2010 at 8:44 AM, Chris Turner c.tur...@199technologies.org wrote: Matthew Dillon wrote: Partitioning is already desireable for the current 48-core monster and I'd like to have some sort of DragonFly host guest solution that runs at full performance on the bare HW without virtualization. How would this be different than jail(8)? not understanding the 'without virtualization' part - I know some form of HW virt a-la kvm has been discussed a few times - I think that Matthew is talking about something like these : http://en.wikipedia.org/wiki/Logical_Domains http://en.wikipedia.org/wiki/Logical_partition_%28virtual_computing_platform%29 do you mean like segmenting the 'machine' or somesuch?
Re: Random x86-64 seg-fault finally fixed
Matthew Dillon wrote: Partitioning is already desireable for the current 48-core monster and I'd like to have some sort of DragonFly host guest solution that runs at full performance on the bare HW without virtualization. How would this be different than jail(8)? not understanding the 'without virtualization' part - I know some form of HW virt a-la kvm has been discussed a few times - do you mean like segmenting the 'machine' or somesuch?
Re: Random x86-64 seg-fault finally fixed
Matthew Dillon dil...@apollo.backplane.com wrote: I also expect to have a fine-grained VM solution at least for standard VM faults by the next release, hopefully sooner. It appears to be the biggest bottleneck on the monster 48-core test box now. Just out of curiosity, are there any plans for supporting machines with 64 cores or even more? For example, the Sun Fire X4800 (quite common in larger data centers) supports eight Xeon 7500 packages which have eight cores plus hyperthreading, which gives a 128-way SMP system. Solaris, Linux and Windows support them, but I don't think any of the BSDs does. And that's certainly not the end. 256-way x86 systems have been announced already. Basically, it seems that the growth of the number of cores has taken over the role of the growth of clockrate (because the latter starts to face physical limits). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
Re: Random x86-64 seg-fault finally fixed
:Just out of curiosity, are there any plans for supporting :machines with 64 cores or even more? : :For example, the Sun Fire X4800 (quite common in larger data :centers) supports eight Xeon 7500 packages which have eight :cores plus hyperthreading, which gives a 128-way SMP system. :Solaris, Linux and Windows support them, but I don't think :any of the BSDs does. : :And that's certainly not the end. 256-way x86 systems have :been announced already. Basically, it seems that the growth :of the number of cores has taken over the role of the growth :of clockrate (because the latter starts to face physical :limits). : :Best regards : Oliver The basic limitation here for us the convenience of being able to operate atomically on cpu masks and in particular being able to run bit-search instructions on them (bsfq, etc). There are also a few places where I combine cpu masking operations with a spin lock, which is ultra convenient. I would have to rewrite those algorithms to operate on an array of cpu masks instead of just one. It isn't in the cards right now though if someone threw a 128-way box onto my carpet I'd probably start working on it :-) Taking x86-64 to 63 cpus was easy because we have 64-bit bit instructions. I'm stealing a bit in the cpumask for a pmap spinlock, or it would be 64. Beyond that it probably makes sense to consider partitioning the hardware with or without virtualization. Partitioning is already desireable for the current 48-core monster and I'd like to have some sort of DragonFly host guest solution that runs at full performance on the bare HW without virtualization. -Matt
Re: Random x86-64 seg-fault finally fixed
Here's hoping everyone has an MPSAFE New Year! And I'm hoping one of these 48-core monsters shows up under my Christmas tree. Tim On Wed, Dec 22, 2010 at 1:19 PM, Matthew Dillon dil...@apollo.backplane.com wrote: The random utility seg-fault (usually cc1) on x86-64 appears to have finally been fixed. It turned out to be a vm_page race in the pageout demon when it cycles pages onto the free page list. This clears the way for running the system with the remaining global tokens set to MPSAFE mode. Test boxes are now running that way with no errors so I expect we will be changing the tokens to run MPSAFE after christmas sometime. We do still have to audit the code paths. I also expect to have a fine-grained VM solution at least for standard VM faults by the next release, hopefully sooner. It appears to be the biggest bottleneck on the monster 48-core test box now. Sascha has brought in the mps disk driver which is now undergoing testing. This is the last big chipset support piece needed for 48-core opteron supermicro support. The Gigabit ethernet uses the igb driver which seems to work pretty well in polling mode. -Matt Matthew Dillon dil...@backplane.com
