Date: Tue, 7 Jul 2015 15:53:18 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: CFT/CFR: NUMA policy branch Message-ID: <CAJ-VmomE4a3R59vbDbZBFcngKOEyNfLs43HW6S_KMbJbxEZHCw@mail.gmail.com> In-Reply-To: <20150707093747.GE2080@kib.kiev.ua> References: <CAJ-Vmo=SnqXTF5m65haKqrVf699zinyXs%2BQdvR6V88CW7vooCw@mail.gmail.com> <CAJ-VmonyTfSxj%2BD=FN3TUCO33w4vGqh1REQqx-8rd-JcArfqSA@mail.gmail.com> <CAJ-Vmo=ON9bEngDoMFK-kJR=qVvcX%2BEeQXx%2BUoEsh1npMHjESQ@mail.gmail.com> <20150707093747.GE2080@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7 July 2015 at 02:37, Konstantin Belousov <kostikbel@gmail.com> wrote: > On Sun, Jul 05, 2015 at 07:06:27PM -0700, Adrian Chadd wrote: >> Hi, >> >> I've done another update. kib@ has been beating me with the clue stick a bit. >> >> https://github.com/freebsd/freebsd/compare/master...erikarn:local/adrian_numa_policy >> >> * (kib) (numactl.c) fix up sorting of include files >> * (kib) (numactl.c) consistent use of values when calling err() >> * (kib) (numactl.c) consistently wrap lines at 78 characters, don't >> prematurely wrap lines >> * (kib) don't use the old-style BSD licence mentioning "regents", use >> the updated one >> * (kib) (vm_domain.c) don't break out after iterating a few times and >> have the API be unpredictable - so now the API will always succeed in >> reading a vm_policy >> >> I've tested the policies (first-touch, fixed-domain, round-robin) and >> they all still work as advertised, both on threads and processes. >> >> I'd appreciate more reviews and some further testing. > > I did not found a fix for the wrong locking of seq_t. Which locking is wrong? * the global policy is locked via the global mutex; * the process/thread policy is locked via PROC_LOCK. What did I miss? > Am I reading sys_numa_getaffinity() right that it does copyout() while > owning the process lock ? I've fixed and push that, thanks. > The things are still syscalls instead of procctl() commands. I haven't done that yet. procctl() doesn't have a concept of per-TID operations at all, and it currently has a framework for iterating over things that this would have to slot into somehow. I'm open to suggestions on how you would integrate per-TID operations into procctl(). > I did not read further, the patch is half-done at best. That's lovely. Meanwhile, people are actively using this thing. -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomE4a3R59vbDbZBFcngKOEyNfLs43HW6S_KMbJbxEZHCw>