Date: Wed, 15 Nov 2017 21:34:53 +0800 From: Julian Elischer <julian@freebsd.org> To: Larry McVoy <lm@mcvoy.com>, Conrad Meyer <cem@freebsd.org> Cc: scottl@netflix.com, kbowling@llnw.com, gallatin@netflix.com, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: small patch for numactl. Comments? Message-ID: <acbbb5cf-6155-9998-6f72-fb4af9634dc8@freebsd.org> In-Reply-To: <20171114140654.GC21209@mcvoy.com> References: <20171114020138.GA18863@mcvoy.com> <CAG6CVpWp6mog9_aP%2BGweN80k2yPH%2BZq_tTKLFq-pzyOjYs1%2B1A@mail.gmail.com> <20171114140654.GC21209@mcvoy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14/11/17 10:06 pm, Larry McVoy wrote:
> Hi Conrad,
>
> Nice idea but pretty awkward compared to checking an env var.
> I'd have to #ifdef up the code for numa (the benchmark in question
> is portable to all the active Unix based systems and a lot of dead
> ones).
>
> Is it not a thing on FreeBSD to use the environment to pass state
> like this?
it's not unheard of, but it's not common.
I can't think of other examples off the top of my head except for
sshd, sudo and other login type things.
there is no reason NOT to other than the fact that you are the only
user of the feature..
You could make it more useful by putting information more useful than
"YES" there..
It also is only useful if you use numactl to do the work.
Any other methods of setting Numa related settings would not have it.
.. Also environments get cleared in many situations.
It's workable solution for you. I'd go with it for now..
>
> --lm
>
> On Mon, Nov 13, 2017 at 08:28:57PM -0800, Conrad Meyer wrote:
>> Hi Larry,
>>
>> What if instead, the benchmark checked its own NUMA parameters? If a
>> NUMA policy is not set, the benchmark can bail out with an
>> admonishment.
>>
>> Best,
>> Conrad
>>
>>
>> On Mon, Nov 13, 2017 at 6:01 PM, Larry McVoy <lm@mcvoy.com> wrote:
>>> Hi folks, some CDN people are dragging me out of retirement to work
>>> on FreeBSD. Which I have to say is sort of fun since I started my
>>> kernel hacking on SunOS 4.x which was a very very nice version of
>>> BSD. But FreeBSD has mostly caught up, so it's pleasant.
>>>
>>> I'm wacking LMbench to be numa aware and this patch would help me make
>>> sure that when you are a numa machine you could insist that people
>>> run the benchmark via numactl (imma gonna blog about numa, it sucks
>>> unless you are numa aware).
>>>
>>> I did some docs but I'm new to the FreeBSD man macros, would love
>>> feedback on how to do that right.
>>>
>>> --- numactl.1 2017-11-13 17:51:26.243473000 -0800
>>> +++ numactl.1.lm 2017-11-13 17:51:20.494596000 -0800
>>> @@ -107,6 +107,15 @@
>>> .El
>>> .Sh EXIT STATUS
>>> .Ex -std
>>> +.Sh ENVIRONMENT
>>> +.Nm
>>> +sets the environment variable
>>> +\fINUMACTL=YES\fP
>>> +before running
>>> +.Ar cmd ...
>>> +so that programs that know that they need to be run under
>>> +.Nm
>>> +can check.
>>> .Sh EXAMPLES
>>> Create a
>>> .Pa /bin/sh
>>> --- numactl.c 2017-11-13 16:18:36.134359000 -0800
>>> +++ numactl.c.lm 2017-11-13 16:18:28.530953000 -0800
>>> @@ -231,6 +231,7 @@
>>> (void) set_numa_domain_cpuaffinity(cpu_domain,
>>> CPU_WHICH_PID, -1);
>>>
>>> + putenv("NUMACTL=YES");
>>> errno = 0;
>>> execvp(*argv, argv);
>>> err(errno == ENOENT ? 127 : 126, "%s", *argv);
>>> _______________________________________________
>>> freebsd-arch@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
>>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?acbbb5cf-6155-9998-6f72-fb4af9634dc8>