Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932156AbcDSNa2 (ORCPT ); Tue, 19 Apr 2016 09:30:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36722 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932137AbcDSNaY (ORCPT ); Tue, 19 Apr 2016 09:30:24 -0400 Date: Tue, 19 Apr 2016 09:30:21 -0400 From: Luiz Capitulino To: John Kacur Cc: Clark Williams , RT , LKML Subject: Re: [PATCH] cyclictest: avoid using libnuma cpumask parsing functions Message-ID: <20160419093021.0a61742e@redhat.com> In-Reply-To: References: <20160413153700.7a930369@sluggy.hsv.redhat.com> <20160414103018.3a07cf27@redhat.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2039 Lines: 46 On Tue, 19 Apr 2016 15:17:33 +0200 (CEST) John Kacur wrote: > On Thu, 14 Apr 2016, Luiz Capitulino wrote: > > > On Wed, 13 Apr 2016 15:37:00 -0500 > > Clark Williams wrote: > > > > > John, > > > > > > I ran into issues with parsing cpu masks when trying to run this command: > > > > > > sudo ./cyclictest -i100 -qmu -h 2000 -p95 -t1 -a3 > > > > > > I had previously booted a 4-core system with these boot options: > > > > > > isolcpus=3 nohz_full=3 rcu_nocbs=3 > > > > > > The intent was to run loads on cpus 0-2 while running cyclictest on the isolated cpu 3. > > > > > > Unfortunately, the libnuma function numa_parse_cpumask() (which we use when it's available) seems to check the current affinity mask and fails the parse if any of the cpus in the input string are not in the current affinity mask. I find this "unhelpful" when trying to place a measurement thread on an isolated cpu. > > > > > > This patch removes the wrapper function which uses libnuma cpumask parsing functions and instead uses the parser function we wrote for when libnuma is not available. > > > > There's an alternative solution that I was working on some time ago, > > which is having a simple configure script. This is usually done > > by simple projects that don't need a full blown autoconf machinery. > > > > The patch below adds such a script. It detects librt, libpthread and > > libnuma. It solves the problem you mention and it removes hardcoded > > lib details from the Makefile. > > > > If there's interest for this solution I can finish it and post for > > inclusion. > > I find this interesting, maybe for the coming new devel system, I wouldn't > want to stick it in now right before a stable release though. Makes sense. > Also, I > like this much better than full blown auto-tools, but I don't want to lose control over > the compiling process either. In otherwords, there should be some way to > override what the script detects. We could implement command-line options.