lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 29 May 2012 19:44:23 +0200 From: Andrea Arcangeli <aarcange@...hat.com> To: Peter Zijlstra <a.p.zijlstra@...llo.nl> Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, Hillf Danton <dhillf@...il.com>, Dan Smith <danms@...ibm.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton <akpm@...ux-foundation.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>, Paul Turner <pjt@...gle.com>, Suresh Siddha <suresh.b.siddha@...el.com>, Mike Galbraith <efault@....de>, "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, Lai Jiangshan <laijs@...fujitsu.com>, Bharata B Rao <bharata.rao@...il.com>, Lee Schermerhorn <Lee.Schermerhorn@...com>, Rik van Riel <riel@...hat.com>, Johannes Weiner <hannes@...xchg.org>, Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>, Christoph Lameter <cl@...ux.com> Subject: Re: [PATCH 08/35] autonuma: introduce kthread_bind_node() On Tue, May 29, 2012 at 07:04:51PM +0200, Peter Zijlstra wrote: > doing it without mention and keeping a misleading comment near the > definition. Right, I forgot to update the comment, I fixed it now. diff --git a/include/linux/sched.h b/include/linux/sched.h index 60a699c..0b84494 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1788,7 +1788,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 */ > Just teach each knuma_migrated what node it represents and don't use > numa_node_id(). It already works like that, I absolutely never use numa_node_id(), I always use the pgdat passed as parameter to the kernel thread through the pointer parameter. But it'd be totally bad not to do the hard bindings to the cpu_s_ of the node, and not using PF_THREAD_BOUND would just allow userland to shoot itself in the foot. I mean if PF_THREAD_BOUND wouldn't exist already I wouldn't add it, but considering somebody bothered to implement it for the sake to make userland root user "safer", it'd be really silly not to take advantage of that for knuma_migrated too (even if it binds to more than 1 CPU). Additionally I added a bugcheck in the main knuma_migrated loop: VM_BUG_ON(numa_node_id() != pgdat->node_id); to be sure it never goes wrong. This above bugcheck is what allowed me to find a bug in the numa emulation fixed in commit d71b5a73fe9af42752c4329b087f7911b35f8f79. > That way you can change the affinity just fine, it'll be sub-optimal, > copying memory from node x to node y through node z, but it'll still > work correctly. I don't think allowing userland to do suboptimal things (even if it will only decrease performance and still work correctly) makes sense (considering somebody added PF_THREAD_BOUND already and it's zero cost to use). > numa isn't special in the way per-cpu stuff is special. Agreed that it won't be as bad as getting per-cpu stuff wrong, it only slowdown -50% in the worst case, but it's a guaranteed regression in the best case too, so there's no reason to allow root to shoot itself in the foot. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists