What happened to computer architecture (and comp.arch?)
|
Prev: VMWare tools killed my Mac OS X ?
Next: Software vs hardware floating-point [was Re: What happened ...]
From: Petter Gustad on 5 Oct 2009 04:17 Morten Reistad <first(a)last.name> writes: > The things I am specifically looking out for are cache coherency and You might want to take a look at the Numachip (SCI distributed directory cache coherency) from Numascale (http://www.numascale.com). Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
From: nmm1 on 5 Oct 2009 04:34 In article <3Qfym.24727$La7.21293(a)uutiset.elisa.fi>, Kim Enkovaara <kim.enkovaara(a)iki.fi> wrote: >nmm1(a)cam.ac.uk wrote: >> Morten Reistad <first(a)last.name> wrote: >>> Are the memory and cache access counters on the xeons accessible from a >>> Linux environment ? >> >> As far as I know, they are still "work in progress" except for the >> Itanium. Part of the problem is that Intel and AMD won't disclose >> the interfaces. > >My understanding is that they are quite well supported. For example >see the "event type" section in oprofile documentation >(http://oprofile.sourceforge.net/docs/) > >There is also new tool called perf for linux, but I have not tried that >yet. Thanks very much. I must experiment again. When I last looked, it needed a hacked kernel, and was available only for a few rather ancient ones. From a quick look at the documentation, it may not help Morten, anyway, because of the way it is implemented. Interrupt-driven tracing is NOT good news when investigating problems with code that is already dominated by interrupts! Solaris dtrace would be more useful for that. Regards, Nick Maclaren.
From: Kim Enkovaara on 5 Oct 2009 08:42 nmm1(a)cam.ac.uk wrote: > From a quick look at the documentation, it may not help Morten, > anyway, because of the way it is implemented. Interrupt-driven > tracing is NOT good news when investigating problems with code > that is already dominated by interrupts! Maybe the new perf on 2.6.31 could be more helpful to Morten. There are some examples in the kernelnewbies releaste note which list cache misses etc. http://kernelnewbies.org/Linux_2_6_31#head-6004ec219c203c60037057dbebaf0a04fe22f19c --Kim
From: nmm1 on 5 Oct 2009 09:49 In article <ZQlym.24813$La7.15537(a)uutiset.elisa.fi>, Kim Enkovaara <kim.enkovaara(a)iki.fi> wrote: > >> From a quick look at the documentation, it may not help Morten, >> anyway, because of the way it is implemented. Interrupt-driven >> tracing is NOT good news when investigating problems with code >> that is already dominated by interrupts! > >Maybe the new perf on 2.6.31 could be more helpful to Morten. There >are some examples in the kernelnewbies releaste note which list cache >misses etc. I doubt it. The output wasn't my point. It is FIENDISHLY hard to write interrupt handling code that is robust against interrupts occurring within interrupts - even when you use a very weak meaning of the term "robust". Most such code will lose a lot of interrupts, at best, and very often lead to the system getting completely knotted. A related problem is that incidence of such race conditions is quadratic in the interrupt rate, at best, and very often cubic or worse. If he is already pushing the interrupt rate tolerance of a system, adding more (and very high priority ones, remember), this problem will hit hard. That is why I have posted why I think that modern architecture is seriously outdated and mistaken, and a new generation should move to an interrupt-free design. It could be done. Regards, Nick Maclaren.
From: Morten Reistad on 5 Oct 2009 11:20
In article <hacth1$b5o$1(a)smaug.linux.pwf.cam.ac.uk>, <nmm1(a)cam.ac.uk> wrote: >In article <ZQlym.24813$La7.15537(a)uutiset.elisa.fi>, >Kim Enkovaara <kim.enkovaara(a)iki.fi> wrote: >> >>> From a quick look at the documentation, it may not help Morten, >>> anyway, because of the way it is implemented. Interrupt-driven >>> tracing is NOT good news when investigating problems with code >>> that is already dominated by interrupts! >> >>Maybe the new perf on 2.6.31 could be more helpful to Morten. There >>are some examples in the kernelnewbies releaste note which list cache >>misses etc. > >I doubt it. The output wasn't my point. > >It is FIENDISHLY hard to write interrupt handling code that is >robust against interrupts occurring within interrupts - even when >you use a very weak meaning of the term "robust". Most such code >will lose a lot of interrupts, at best, and very often lead to the >system getting completely knotted. > >A related problem is that incidence of such race conditions is >quadratic in the interrupt rate, at best, and very often cubic or >worse. If he is already pushing the interrupt rate tolerance of a >system, adding more (and very high priority ones, remember), this >problem will hit hard. > >That is why I have posted why I think that modern architecture is >seriously outdated and mistaken, and a new generation should move >to an interrupt-free design. It could be done. The interrupt-coalescing code helps bring the interrupt rate down by an order of magnitude, so the interrupt rate is not a showstopper anymore. I have a strong stomack feeling there is something going on regarding l2 cache hit rate. -- mrr |