From: Petter Gustad on
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
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
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
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
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