Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [hwloc-devel] Cacheline sizes
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2010-05-25 15:00:31


On 25/05/2010 20:45, Wheeler, Kyle Bruce wrote:
> Hello!
>
> I noticed that hwloc doesn't appear to have a way of reporting (minimum) cache line size... which is obviously useful and important for avoiding false-sharing issues. I've been hacking together a way to do it in what passes for a cross-platform method. My code is currently in qthreads (http://www.cs.sandia.gov/qthreads/), in the cacheline.c file. Would this be something that the hwloc developers would be interested in integrating into hwloc?
>

Numerous ideas like this were proposed and we're not sure where to stop.
If we start doing this, people will ask for the processor frequency, the
number of floating point units per core, the associativity of the cache,
the type of memory, ... lots of things that are not really related to
topology but may be useful to some applications. Cache line size isn't
that bad, but it's borderline, so I don't know if we want it. There are
many other specific tools to gather such random hardware information,
merging all of them inside hwloc wouldn't be good.

Talking about caches, one thing we need to think about is Instruction
caches (we only gather Data and Unified caches on Linux so far).

Brice