[PATCH] RFC - rt-tools: Detect whether numa is available at build time

[PATCH] RFC - rt-tools: Detect whether numa is available at build time

[John Kacur]

This is a preliminary hack, I need to clean it up a little, but incase you
want to give it a try, here is the alpha version.

Note - I stole this methodology from tools/perf

Signed-off-by: John Kacur <jkacur@redhat.com>
---
 Makefile                 |   33 +++++++++++++++++++++++++++------
 config/feature-tests.mak |    8 ++++++++
 config/utilities.mak     |    7 +++++++
 3 files changed, 42 insertions(+), 6 deletions(-)
 create mode 100644 config/feature-tests.mak
 create mode 100644 config/utilities.mak

diff --git a/Makefile b/Makefile
index 3a82407..33f5027 100644
--- a/Makefile
+++ b/Makefile
@@ -16,9 +16,6 @@ srcdir	?= $(prefix)/src
 
 machinetype = $(shell $(CC) -dumpmachine | \
     sed -e 's/-.*//' -e 's/i.86/i386/' -e 's/mips.*/mips/' -e 's/ppc.*/powerpc/')
-ifneq ($(filter x86_64 i386 ia64 mips powerpc,$(machinetype)),)
-NUMA 	:= 1
-endif
 
 CFLAGS ?= -D_GNU_SOURCE -Wall -Wno-nonnull -Isrc/include
 LDFLAGS ?=
@@ -31,9 +28,33 @@ else
 	CFLAGS	+= -O0 -g
 endif
 
-ifeq ($(NUMA),1)
-	CFLAGS += -DNUMA
-	NUMA_LIBS = -lnuma
+ifeq ("$(origin O)", "command line")
+	OUTPUT := $(O)/
+endif
+
+ifneq ($(OUTPUT),)
+# check that the output directory actually exists
+OUTDIR := $(shell cd $(OUTPUT) && /bin/pwd)
+$(if $(OUTDIR),, $(error output directory "$(OUTPUT)" does not exist))
+endif
+
+include config/utilities.mak
+include config/feature-tests.mak
+
+ifeq ($(NUMA),0)
+	NO_NUMA=0
+endif
+
+ifdef NO_NUMA
+	CFLAGS += -DNO_NUMA_SUPPORT
+else
+	ifneq ($(call try-cc,$(SOURCE_NUMA),-lnuma),y)
+		msg := $(warning numa not found. Install numactl-devel to build with numa support);
+		CFLAGS += -DNO_NUMA_SUPPORT
+	else
+		CFLAGS += -DNUMA
+		NUMA_LIBS = -lnuma
+	endif
 endif
 
 VPATH	= src/cyclictest:
diff --git a/config/feature-tests.mak b/config/feature-tests.mak
new file mode 100644
index 0000000..8fb61ea
--- /dev/null
+++ b/config/feature-tests.mak
@@ -0,0 +1,8 @@
+ifndef NO_NUMA
+define SOURCE_NUMA
+int main(void)
+{
+	return numa_available();
+}
+endef
+endif
diff --git a/config/utilities.mak b/config/utilities.mak
new file mode 100644
index 0000000..da7c434
--- /dev/null
+++ b/config/utilities.mak
@@ -0,0 +1,7 @@
+# try-cc
+# Usage: option = $(call try-cc, source-to-build, cc-options)
+try-cc = $(shell sh -c						  \
+	'TMP="$(OUTPUT)$(TMPOUT).$$$$";				  \
+	 echo "$(1)" |						  \
+	 $(CC) -x c - $(2) -o "$$TMP" > /dev/null 2>&1 && echo y; \
+	 rm -f "$$TMP"')
-- 
1.7.7.6

Re: [PATCH] RFC - rt-tools: Detect whether numa is available at build time

[Frank Rowand]

On 05/25/12 16:39, John Kacur wrote:
> This is a preliminary hack, I need to clean it up a little, but incase you
> want to give it a try, here is the alpha version.
> 
> Note - I stole this methodology from tools/perf
> 
> Signed-off-by: John Kacur <jkacur@redhat.com>

I knew I would regret suggesting this fix.

It works fine on my fedora 12 x86_64 system for native build.

It works fine on my fedora 12 x86_64 system for crossbuild for ARM.

The NUMA=0 option is still useful (thank you for leaving that
in place).  I have a second ARM target board, where the cross
linker does not complain about libnuma, so cyclictest is
build with libnuma.  But my run time environment does not have
a libnuma.  Ah the joy of pre-release file systems.  The NUMA=0
option allowed me to properly build cyclictest to run on this
not quite yet finished file system.

Tested-by: Frank Rowand <frank.rowand@am.sony.com>

-Frank

Re: [PATCH] RFC - rt-tools: Detect whether numa is available at build time

[John Kacur]

On Tue, May 29, 2012 at 2:49 AM, Frank Rowand <frank.rowand@am.sony.com> wrote:
>
> On 05/25/12 16:39, John Kacur wrote:
> > This is a preliminary hack, I need to clean it up a little, but incase
> > you
> > want to give it a try, here is the alpha version.
> >
> > Note - I stole this methodology from tools/perf
> >
> > Signed-off-by: John Kacur <jkacur@redhat.com>
>
> I knew I would regret suggesting this fix.
>
> It works fine on my fedora 12 x86_64 system for native build.
>
> It works fine on my fedora 12 x86_64 system for crossbuild for ARM.
>
> The NUMA=0 option is still useful (thank you for leaving that
> in place).  I have a second ARM target board, where the cross
> linker does not complain about libnuma, so cyclictest is
> build with libnuma.  But my run time environment does not have
> a libnuma.  Ah the joy of pre-release file systems.  The NUMA=0
> option allowed me to properly build cyclictest to run on this
> not quite yet finished file system.
>
> Tested-by: Frank Rowand <frank.rowand@am.sony.com>
>

Thank you very much for testing my quick hack. (tglx has anointed it
the beer on the couch hack)
What happens when you run a compiled with libnuma binary on a ARM
target that doesn't have numa, as long as you don't supply the numa
function?

Thanks
John
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] RFC - rt-tools: Detect whether numa is available at build time

[Frank Rowand]

On 05/30/12 12:58, John Kacur wrote:
> On Tue, May 29, 2012 at 2:49 AM, Frank Rowand <frank.rowand@am.sony.com> wrote:
>>
>> On 05/25/12 16:39, John Kacur wrote:
>>> This is a preliminary hack, I need to clean it up a little, but incase
>>> you
>>> want to give it a try, here is the alpha version.
>>>
>>> Note - I stole this methodology from tools/perf
>>>
>>> Signed-off-by: John Kacur <jkacur@redhat.com>
>>
>> I knew I would regret suggesting this fix.
>>
>> It works fine on my fedora 12 x86_64 system for native build.
>>
>> It works fine on my fedora 12 x86_64 system for crossbuild for ARM.
>>
>> The NUMA=0 option is still useful (thank you for leaving that
>> in place).  I have a second ARM target board, where the cross
>> linker does not complain about libnuma, so cyclictest is
>> build with libnuma.  But my run time environment does not have
>> a libnuma.  Ah the joy of pre-release file systems.  The NUMA=0
>> option allowed me to properly build cyclictest to run on this
>> not quite yet finished file system.
>>
>> Tested-by: Frank Rowand <frank.rowand@am.sony.com>
>>
> 
> Thank you very much for testing my quick hack. (tglx has anointed it
> the beer on the couch hack)
> What happens when you run a compiled with libnuma binary on a ARM
> target that doesn't have numa, as long as you don't supply the numa
> function?

I'm not sure if I understand your question.  But if I build with libnuma
then try to run it on a target that does not have the library, I get:

$ ./cyclictest_numa
./cyclictest_numa: error while loading shared libraries: libnuma.so.1: cannot open shared object file: No such file or directory

Which is not surprising, given:

$ ldd ./cyclictest_numa 
        librt.so.1 => /devel/lib/librt.so.1 (0xb6f4d000)
        libpthread.so.0 => /devel/lib/libpthread.so.0 (0xb6f2d000)
        libnuma.so.1 => not found
        libgcc_s.so.1 => /devel/usr/lib/libgcc_s.so.1 (0xb6f1a000)
        libc.so.6 => /devel/lib/libc.so.6 (0xb6de2000)
        /devel/lib/ld-linux.so.3 (0xb6f5c000)

-Frank