[lkml]   [2012]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 09/40] autonuma: introduce kthread_bind_node()
    On Fri, Jun 29, 2012 at 11:36:26AM -0400, Rik van Riel wrote:
    > On 06/28/2012 08:55 AM, Andrea Arcangeli wrote:
    > > --- a/include/linux/sched.h
    > > +++ b/include/linux/sched.h
    > > @@ -1792,7 +1792,7 @@ extern void thread_group_times(struct task_struct *p, cputime_t *ut, cputime_t *
    > > #define PF_SWAPWRITE 0x00800000 /* Allowed to write to swap */
    > > #define PF_SPREAD_PAGE 0x01000000 /* Spread page cache over cpuset */
    > > #define PF_SPREAD_SLAB 0x02000000 /* Spread some slab caches over cpuset */
    > > -#define PF_THREAD_BOUND 0x04000000 /* Thread bound to specific cpu */
    > > +#define PF_THREAD_BOUND 0x04000000 /* Thread bound to specific cpus */
    > > #define PF_MCE_EARLY 0x08000000 /* Early kill for mce process policy */
    > > #define PF_MEMPOLICY 0x10000000 /* Non-default NUMA mempolicy */
    > > #define PF_MUTEX_TESTER 0x20000000 /* Thread belongs to the rt mutex tester */
    > Changing the semantics of PF_THREAD_BOUND without so much as
    > a comment in your changelog or buy-in from the scheduler
    > maintainers is a big no-no.
    > Is there any reason you even need PF_THREAD_BOUND in your
    > kernel numa threads?
    > I do not see much at all in the scheduler code that uses
    > PF_THREAD_BOUND and it is not clear at all that your
    > numa threads get any benefit from them...
    > Why do you think you need it?

    Nobody needs that flag anyway, you can drop the flag from the kernel
    in all places it used, it is never "needed", but since somebody
    bothered to add this reliability feature to the kernel, why not to
    take advantage of it whenever possible?

    This flag is only used to prevent userland to mess with the kernel CPU
    binds of kernel threads. It is used to avoid the root user to shoot
    itself in the foot.

    So far it has been used to prevent changing bindings to a single
    CPU. I'm setting it also after making a multiple-cpu bind (all CPUs of
    the node, instead of just 1 CPU). I hope it's clear to everybody that
    this is perfectly ok usage and if it the bind is done on 1 CPU or 10 CPUs
    or all CPUs, nothing changes for how the bitflag works.

    There's no legitimate reason to allow the root user to change the CPU
    binding of knuma_migratedN. Any change would be a guaranteed
    regression. So there's no reason not to enforce the NODE wide binding,
    if nothing else to document that the binding enforced is the ideal one
    in all possible conditions.

     \ /
      Last update: 2012-06-29 19:21    [W:0.030 / U:40.168 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site