linux-kernel - Re: RFC: NUMA modifications to cyclictest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100120073734.4be7a52b@torg>
Date:	Wed, 20 Jan 2010 07:37:34 -0600
From:	Clark Williams <williams@...hat.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	RT <linux-rt-users@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, Carsten Emde <ce@...g.ch>,
	John Kacur <jkacur@...hat.com>
Subject: Re: RFC: NUMA modifications to cyclictest

On Wed, 20 Jan 2010 07:51:41 +0100 (CET)
Thomas Gleixner <tglx@...utronix.de> wrote:

> On Tue, 19 Jan 2010, Clark Williams wrote:
> > RT-ers,
> > 
> > Lately we've been struggling with some performance issues on high-core
> > count (>16 cores) NUMA machines with the RT kernel. During the course
> > of troubleshooting this issue, we tried using the 'numactl' program to
> > constrain our measurement testing tool (rteval) to a particular memory
> > node, rather than letting everything float. Doing so showed marked
> > improvement in both max latency and jitter.  While this doesn't solve
> > our performance problems I thought it might make sense to have a --numa
> > mode for cylictest that compliments the --smp mode just added. 
> > 
> > The big difference here is that when using --numa, each measurement
> > thread (one per cpu) has it's stack allocated from the memory node
> > associated with it's cpu. Also, the major data structures for each
> > thread (parameter block, statistics block and histogram) are allocated
> > from the appropriate node. This is done with calls into libnuma,
> > which means this will add a dependency on libnuma. 
> 
> That might cause some trouble for embedded folks. :(

Yeah, that's why I send the RFC, wanted to see who would hate me for
it :).

Carsten already told me off-list that one of his build machines didn't
have numa.h, so I'm going to have to rearrange the build a bit.

As much as I hate to say it, I think the best option is to use autoconf
to detect if libnuma is available on the build platform and to take
appropriate steps if it's not. 

The other idea I toyed with was dynamic loading of libnuma so there's
not an install dependency for the libnuma package with the rt-tests
package. I only use five functions from libnuma, so that's not too bad
a set of function pointers to manage. Hmmm, that probably won't work
very well, since I'll still have to include numa.h. Sigh...

Clark

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)