Re: [PATCH 09/40] autonuma: introduce kthread_bind_node()
From: Rik van Riel <hidden>
Date: 2012-06-29 15:37:25
Also in:
lkml
On 06/28/2012 08:55 AM, Andrea Arcangeli wrote:
quoted hunk ↗ jump to hunk
--- 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? -- All rights reversed -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>