Re: [PATCH 00/36] AutoNUMA24
* Andrea Arcangeli wrote: > On Wed, Aug 22, 2012 at 11:40:48PM +0200, Ingo Molnar wrote: > > > > * Rik van Riel wrote: > > > > > On 08/22/2012 10:58 AM, Andrea Arcangeli wrote: > > > >Hello everyone, > > > > > > > >Before the Kernel Summit, I think it's good idea to post a new > > > >AutoNUMA24 and to go through a new review cycle. The last review cycle > > > >has been fundamental in improving the patchset. Thanks! > > > > > > Thanks for improving the code and incorporating all our > > > feedback. The AutoNUMA codebase is now in a state where I can > > > live with it. > > > > > > I hope the code will be acceptable to others, too. > > > > Lots of scheduler changes. Has all of peterz's review feedback > > been addressed? > > git diff --stat origin kernel/sched/ > kernel/sched/Makefile |1 + > kernel/sched/core.c |1 + > kernel/sched/fair.c | 86 ++- > kernel/sched/numa.c | 604 > + > kernel/sched/sched.h | 19 ++ > 5 files changed, 699 insertions(+), 12 deletions(-) > > Lots of scheduler changes only if CONFIG_AUTONUMA=y. That's a lot of scheduler changes. > [...] If CONFIG_AUTONUMA=n it's just 107 lines of scheduler > changes (numa.c won't get built in that case). > > > Hm, he isn't even Cc:-ed, how is that supposed to work? > > I separately forwarded him the announcement email because I > wanted to add a few more (minor) details for him. Of course > Peter's review is fundamental and appreciated and already > helped to make the code a lot better. I see no reason why such details shouldn't be discussed openly and why forwarding him things separately should cause you to drop a scheduler co-maintainer from the Cc:, with a 700 lines kernel/sched/ diffstat ... > His previous comments should have been addressed, [...] That's good news. Peter? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/36] AutoNUMA24
* Andrea Arcangeli aarca...@redhat.com wrote: On Wed, Aug 22, 2012 at 11:40:48PM +0200, Ingo Molnar wrote: * Rik van Riel r...@redhat.com wrote: On 08/22/2012 10:58 AM, Andrea Arcangeli wrote: Hello everyone, Before the Kernel Summit, I think it's good idea to post a new AutoNUMA24 and to go through a new review cycle. The last review cycle has been fundamental in improving the patchset. Thanks! Thanks for improving the code and incorporating all our feedback. The AutoNUMA codebase is now in a state where I can live with it. I hope the code will be acceptable to others, too. Lots of scheduler changes. Has all of peterz's review feedback been addressed? git diff --stat origin kernel/sched/ kernel/sched/Makefile |1 + kernel/sched/core.c |1 + kernel/sched/fair.c | 86 ++- kernel/sched/numa.c | 604 + kernel/sched/sched.h | 19 ++ 5 files changed, 699 insertions(+), 12 deletions(-) Lots of scheduler changes only if CONFIG_AUTONUMA=y. That's a lot of scheduler changes. [...] If CONFIG_AUTONUMA=n it's just 107 lines of scheduler changes (numa.c won't get built in that case). Hm, he isn't even Cc:-ed, how is that supposed to work? I separately forwarded him the announcement email because I wanted to add a few more (minor) details for him. Of course Peter's review is fundamental and appreciated and already helped to make the code a lot better. I see no reason why such details shouldn't be discussed openly and why forwarding him things separately should cause you to drop a scheduler co-maintainer from the Cc:, with a 700 lines kernel/sched/ diffstat ... His previous comments should have been addressed, [...] That's good news. Peter? Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/36] AutoNUMA24
On Wed, Aug 22, 2012 at 11:40:48PM +0200, Ingo Molnar wrote: > > * Rik van Riel wrote: > > > On 08/22/2012 10:58 AM, Andrea Arcangeli wrote: > > >Hello everyone, > > > > > >Before the Kernel Summit, I think it's good idea to post a new > > >AutoNUMA24 and to go through a new review cycle. The last review cycle > > >has been fundamental in improving the patchset. Thanks! > > > > Thanks for improving the code and incorporating all our > > feedback. The AutoNUMA codebase is now in a state where I can > > live with it. > > > > I hope the code will be acceptable to others, too. > > Lots of scheduler changes. Has all of peterz's review feedback > been addressed? git diff --stat origin kernel/sched/ kernel/sched/Makefile |1 + kernel/sched/core.c |1 + kernel/sched/fair.c | 86 ++- kernel/sched/numa.c | 604 + kernel/sched/sched.h | 19 ++ 5 files changed, 699 insertions(+), 12 deletions(-) Lots of scheduler changes only if CONFIG_AUTONUMA=y. If CONFIG_AUTONUMA=n it's just 107 lines of scheduler changes (numa.c won't get built in that case). > Hm, he isn't even Cc:-ed, how is that supposed to work? I separately forwarded him the announcement email because I wanted to add a few more (minor) details for him. Of course Peter's review is fundamental and appreciated and already helped to make the code a lot better. His previous comments should have been addressed, the documentation of sched_autonuma_balance has been rewritten from scratch, PF_THREAD_BOUND is gone, etc... It's possible we'll have to go through more rewrites of the docs if this still isn't good enough. I don't know yet. This is what the review is about after all :). numa.c is self contained but I see it as a plus that it's self contained. First it's easy to nuke AutoNUMA by just deleting the .[ch] files and fixing up the build errors as result in case a better algorithm emerges in the future. Second it's trivial to proof those 107 lines won't regress CFS when CONFIG_AUTONUMA=n. About the CFS integration: sched_autonuma_balance() is simply yet another idle active load balancing method. The idle active load balancing that with hyperthreading takes care of distributing the threads to be sure to fill all idle cores, in principle works identical to AutoNUMA. It also works side by side with CFS and moves tasks under CFS control (without CFS possibly noticing) to optimize for HT. numa.c in principle does the exact same thing (and it also calls the very same stop_one_cpu_nowait to do the migrations) but it optimizes for NUMA instead of HT. Thanks, Andrea -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/36] AutoNUMA24
* Rik van Riel wrote: > On 08/22/2012 10:58 AM, Andrea Arcangeli wrote: > >Hello everyone, > > > >Before the Kernel Summit, I think it's good idea to post a new > >AutoNUMA24 and to go through a new review cycle. The last review cycle > >has been fundamental in improving the patchset. Thanks! > > Thanks for improving the code and incorporating all our > feedback. The AutoNUMA codebase is now in a state where I can > live with it. > > I hope the code will be acceptable to others, too. Lots of scheduler changes. Has all of peterz's review feedback been addressed? Hm, he isn't even Cc:-ed, how is that supposed to work? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/36] AutoNUMA24
On 08/22/2012 10:58 AM, Andrea Arcangeli wrote: Hello everyone, Before the Kernel Summit, I think it's good idea to post a new AutoNUMA24 and to go through a new review cycle. The last review cycle has been fundamental in improving the patchset. Thanks! Thanks for improving the code and incorporating all our feedback. The AutoNUMA codebase is now in a state where I can live with it. I hope the code will be acceptable to others, too. The objective of AutoNUMA is to be able to perform as close as possible to (and sometime faster than) the NUMA hard CPU/memory bindings setups, without requiring the administrator to manually setup any NUMA hard bind. It is a difficult problem, but the performance numbers I have seen before (with older versions) seem to suggest that AutoNUMA is accomplishing the goal. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/36] AutoNUMA24
On 08/22/2012 10:58 AM, Andrea Arcangeli wrote: Hello everyone, Before the Kernel Summit, I think it's good idea to post a new AutoNUMA24 and to go through a new review cycle. The last review cycle has been fundamental in improving the patchset. Thanks! Thanks for improving the code and incorporating all our feedback. The AutoNUMA codebase is now in a state where I can live with it. I hope the code will be acceptable to others, too. The objective of AutoNUMA is to be able to perform as close as possible to (and sometime faster than) the NUMA hard CPU/memory bindings setups, without requiring the administrator to manually setup any NUMA hard bind. It is a difficult problem, but the performance numbers I have seen before (with older versions) seem to suggest that AutoNUMA is accomplishing the goal. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/36] AutoNUMA24
* Rik van Riel r...@redhat.com wrote: On 08/22/2012 10:58 AM, Andrea Arcangeli wrote: Hello everyone, Before the Kernel Summit, I think it's good idea to post a new AutoNUMA24 and to go through a new review cycle. The last review cycle has been fundamental in improving the patchset. Thanks! Thanks for improving the code and incorporating all our feedback. The AutoNUMA codebase is now in a state where I can live with it. I hope the code will be acceptable to others, too. Lots of scheduler changes. Has all of peterz's review feedback been addressed? Hm, he isn't even Cc:-ed, how is that supposed to work? Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/36] AutoNUMA24
On Wed, Aug 22, 2012 at 11:40:48PM +0200, Ingo Molnar wrote: * Rik van Riel r...@redhat.com wrote: On 08/22/2012 10:58 AM, Andrea Arcangeli wrote: Hello everyone, Before the Kernel Summit, I think it's good idea to post a new AutoNUMA24 and to go through a new review cycle. The last review cycle has been fundamental in improving the patchset. Thanks! Thanks for improving the code and incorporating all our feedback. The AutoNUMA codebase is now in a state where I can live with it. I hope the code will be acceptable to others, too. Lots of scheduler changes. Has all of peterz's review feedback been addressed? git diff --stat origin kernel/sched/ kernel/sched/Makefile |1 + kernel/sched/core.c |1 + kernel/sched/fair.c | 86 ++- kernel/sched/numa.c | 604 + kernel/sched/sched.h | 19 ++ 5 files changed, 699 insertions(+), 12 deletions(-) Lots of scheduler changes only if CONFIG_AUTONUMA=y. If CONFIG_AUTONUMA=n it's just 107 lines of scheduler changes (numa.c won't get built in that case). Hm, he isn't even Cc:-ed, how is that supposed to work? I separately forwarded him the announcement email because I wanted to add a few more (minor) details for him. Of course Peter's review is fundamental and appreciated and already helped to make the code a lot better. His previous comments should have been addressed, the documentation of sched_autonuma_balance has been rewritten from scratch, PF_THREAD_BOUND is gone, etc... It's possible we'll have to go through more rewrites of the docs if this still isn't good enough. I don't know yet. This is what the review is about after all :). numa.c is self contained but I see it as a plus that it's self contained. First it's easy to nuke AutoNUMA by just deleting the .[ch] files and fixing up the build errors as result in case a better algorithm emerges in the future. Second it's trivial to proof those 107 lines won't regress CFS when CONFIG_AUTONUMA=n. About the CFS integration: sched_autonuma_balance() is simply yet another idle active load balancing method. The idle active load balancing that with hyperthreading takes care of distributing the threads to be sure to fill all idle cores, in principle works identical to AutoNUMA. It also works side by side with CFS and moves tasks under CFS control (without CFS possibly noticing) to optimize for HT. numa.c in principle does the exact same thing (and it also calls the very same stop_one_cpu_nowait to do the migrations) but it optimizes for NUMA instead of HT. Thanks, Andrea -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
