diff for duplicates of <20261022074044.GA4120091@noisy.programming.kicks-ass.net> diff --git a/a/1.txt b/N1/1.txt index 473d322..1754968 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,58 +1,84 @@ -On Tue, Oct 20, 2026 at 04:37:40PM +0800, Li kunyu wrote: -> [Problem] -> -> It was found that on servers equipped with the Hygon 7447v CPU (Model 7, -> 384 logical cores), migrating tasks across LLC scheduling domains during -> load balancing caused significant performance degradation: -> -> 1. A low L3 cache hitting rate (due to factors such as non-shared L3 -> caches). -> -> 2. The traversal overhead of higher-level scheduling domains (e.g., -> cross-NUMA scheduling domains). -> -> Similar issues were also observed on CPUs from other vendors during -> testing, though the degree of memory bandwidth increase and other -> latency effects varied. Consequently, a series of patches was developed -> to address and improve these issues. -> -> -> [Solution] -> -> This RFC patch series introduces the SMT_BUDDY_ASSIST scheduling -> feature. The main work is as follows: -> -> 1. Push CFS tasks to SMT sibling CPUs during periodic load balancing. -> -> 2. Skip SMT-domain balancing after a successful push and avoid pulling -> the pushed task back. -> -> 3. Restrict newidle balancing so it does not pull from higher-level -> scheduling domains. -> -> 4. Compensate for the resulting load imbalance with a burst-task wakeup -> path that sends tasks to idle CPUs. +From: Peter Zijlstra <peterz@infradead.org>\r -So you're combatting undue LLC migrations with brute force :-( Mostly -this looks like something where cache aware scheduling should help, no? -That ought to make cross-LLC migrations less attractive. - -Now, I realize that cache-aware scheduling as is won't help stream; when -build using OpenMP the whole thing is one big process and cache-aware -mostly gives up, when build using MPI its a ton of single threads and -cache-aware will ignore them. - -Still, I think you really should look that way, perhaps investigate if -something like: - - https://patch.msgid.link/cover.1787955777.git.tim.c.chen%40linux.intel.com - -can help you. - - - - -I'm not sure why you're doing the SMT push thing; but there's this -thing: - - https://patch.msgid.link/20261002154415.2270586-8-vincent.guittot%40linaro.org +On Thu, Oct 22, 2026 at 03:40:44PM +0800, Peter Zijlstra wrote:\r +> On Tue, Oct 20, 2026 at 04:37:40PM +0800, Li kunyu wrote:\r +> > [Problem]\r +> > \r +> > It was found that on servers equipped with the Hygon 7447v CPU (Model 7,\r +> > 384 logical cores), migrating tasks across LLC scheduling domains during\r +> > load balancing caused significant performance degradation:\r +> > \r +> > 1. A low L3 cache hitting rate (due to factors such as non-shared L3\r +> > caches).\r +> > \r +> > 2. The traversal overhead of higher-level scheduling domains (e.g.,\r +> > cross-NUMA scheduling domains).\r +> > \r +> > Similar issues were also observed on CPUs from other vendors during\r +> > testing, though the degree of memory bandwidth increase and other\r +> > latency effects varied. Consequently, a series of patches was developed\r +> > to address and improve these issues.\r +> > \r +> > \r +> > [Solution]\r +> > \r +> > This RFC patch series introduces the SMT_BUDDY_ASSIST scheduling\r +> > feature. The main work is as follows:\r +> > \r +> > 1. Push CFS tasks to SMT sibling CPUs during periodic load balancing.\r +> > \r +> > 2. Skip SMT-domain balancing after a successful push and avoid pulling\r +> > the pushed task back.\r +> > \r +> > 3. Restrict newidle balancing so it does not pull from higher-level\r +> > scheduling domains.\r +> > \r +> > 4. Compensate for the resulting load imbalance with a burst-task wakeup\r +> > path that sends tasks to idle CPUs.\r +> \r +> So you're combatting undue LLC migrations with brute force :-( Mostly\r +> this looks like something where cache aware scheduling should help, no?\r +> That ought to make cross-LLC migrations less attractive.\r +> \r +> Now, I realize that cache-aware scheduling as is won't help stream; when\r +> build using OpenMP the whole thing is one big process and cache-aware\r +> mostly gives up, when build using MPI its a ton of single threads and\r +> cache-aware will ignore them.\r +> \r +> Still, I think you really should look that way, perhaps investigate if\r +> something like:\r +> \r +> https://patch.msgid.link/cover.1787955777.git.tim.c.chen%40linux.intel.com\r +> \r +> can help you.\r +\r +Thank you for your suggestion. I looked at this patch series and think\r +the way it exposes the interface to users ("always" | "advise" |\r +"never") is quite good. We will add the related interfaces in a subsequent\r +version.\r +\r +\r +> I'm not sure why you're doing the SMT push thing; but there's this\r +> thing:\r +> \r +> https://patch.msgid.link/20261002154415.2270586-8-vincent.guittot%40linaro.org\r +\r +I previously looked at the relevant patches, and my implementation\r +approach was slightly different. Here, I mainly focused on quickly\r +distributing tasks to the SMT sibling CPUs; during this load-balancing\r +cycle I could still pull tasks, achieving faster CPU load balancing\r +(mainly for rapid local task dispersal, and it does not substantially\r + conflict with the approach in that patch). In subsequent patches, I\r +also made new considerations: checking the cfs.h_nr_runnable count and\r +no longer focusing on sleeping tasks.\r +\r +Task pushing at the SMT level is part of the overall functionality.\r +Combined with the changes in select_task_rq_fair(), it achieves rapid\r +overall task dispersal.\r +\r +Combined with the aforementioned user interface, this makes it easy to\r +enable or disable SMT-level task pushing.\r +\r +\r +thinks,\r +kunyu diff --git a/a/content_digest b/N1/content_digest index a9d7706..6db59aa 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,77 +1,104 @@ "ref\020261020083746.37068-1-likunyu@open-hieco.net\0" - "From\0Peter Zijlstra <peterz@infradead.org>\0" - "Subject\0Re: [RFC PATCH 0/6] sched/fair: Introduce the SMT_BUDDY_ASSIST feature\0" - "Date\0Thu, 22 Oct 2026 09:40:44 +0200\0" - "To\0Li kunyu <likunyu@open-hieco.net>\0" - "Cc\0mingo@redhat.com" - juri.lelli@redhat.com - vincent.guittot@linaro.org + "From\0Li kunyu <likunyu@open-hieco.net>\0" + "Subject\0Re: [RFC PATCH 0/6] sched/fair: Introduce the SMT BUDDY ASSIST feature\0" + "Date\0Thu, 22 Oct 2026 18:08:21 +0800\0" + "To\0peterz@infradead.org" + " Li kunyu <likunyu@open-hieco.net>\0" + "Cc\0bsegall@google.com" dietmar.eggemann@arm.com - rostedt@goodmis.org - bsegall@google.com - mgorman@suse.de - vschneid@redhat.com + juri.lelli@redhat.com kprateek.nayak@amd.com - " linux-kernel@vger.kernel.org\0" + linux-kernel@vger.kernel.org + mgorman@suse.de + mingo@redhat.com + rostedt@goodmis.org + vincent.guittot@linaro.org + " vschneid@redhat.com\0" "\00:1\0" "b\0" - "On Tue, Oct 20, 2026 at 04:37:40PM +0800, Li kunyu wrote:\n" - "> [Problem]\n" - "> \n" - "> It was found that on servers equipped with the Hygon 7447v CPU (Model 7,\n" - "> 384 logical cores), migrating tasks across LLC scheduling domains during\n" - "> load balancing caused significant performance degradation:\n" - "> \n" - "> 1. A low L3 cache hitting rate (due to factors such as non-shared L3\n" - "> caches).\n" - "> \n" - "> 2. The traversal overhead of higher-level scheduling domains (e.g.,\n" - "> cross-NUMA scheduling domains).\n" - "> \n" - "> Similar issues were also observed on CPUs from other vendors during\n" - "> testing, though the degree of memory bandwidth increase and other\n" - "> latency effects varied. Consequently, a series of patches was developed\n" - "> to address and improve these issues.\n" - "> \n" - "> \n" - "> [Solution]\n" - "> \n" - "> This RFC patch series introduces the SMT_BUDDY_ASSIST scheduling\n" - "> feature. The main work is as follows:\n" - "> \n" - "> 1. Push CFS tasks to SMT sibling CPUs during periodic load balancing.\n" - "> \n" - "> 2. Skip SMT-domain balancing after a successful push and avoid pulling\n" - "> the pushed task back.\n" - "> \n" - "> 3. Restrict newidle balancing so it does not pull from higher-level\n" - "> scheduling domains.\n" - "> \n" - "> 4. Compensate for the resulting load imbalance with a burst-task wakeup\n" - "> path that sends tasks to idle CPUs.\n" - "\n" - "So you're combatting undue LLC migrations with brute force :-( Mostly\n" - "this looks like something where cache aware scheduling should help, no?\n" - "That ought to make cross-LLC migrations less attractive.\n" - "\n" - "Now, I realize that cache-aware scheduling as is won't help stream; when\n" - "build using OpenMP the whole thing is one big process and cache-aware\n" - "mostly gives up, when build using MPI its a ton of single threads and\n" - "cache-aware will ignore them.\n" - "\n" - "Still, I think you really should look that way, perhaps investigate if\n" - "something like:\n" - "\n" - " https://patch.msgid.link/cover.1787955777.git.tim.c.chen%40linux.intel.com\n" - "\n" - "can help you.\n" - "\n" - "\n" - "\n" - "\n" - "I'm not sure why you're doing the SMT push thing; but there's this\n" - "thing:\n" + "From: Peter Zijlstra <peterz@infradead.org>\r\n" "\n" - https://patch.msgid.link/20261002154415.2270586-8-vincent.guittot%40linaro.org + "On Thu, Oct 22, 2026 at 03:40:44PM +0800, Peter Zijlstra wrote:\r\n" + "> On Tue, Oct 20, 2026 at 04:37:40PM +0800, Li kunyu wrote:\r\n" + "> > [Problem]\r\n" + "> > \r\n" + "> > It was found that on servers equipped with the Hygon 7447v CPU (Model 7,\r\n" + "> > 384 logical cores), migrating tasks across LLC scheduling domains during\r\n" + "> > load balancing caused significant performance degradation:\r\n" + "> > \r\n" + "> > 1. A low L3 cache hitting rate (due to factors such as non-shared L3\r\n" + "> > caches).\r\n" + "> > \r\n" + "> > 2. The traversal overhead of higher-level scheduling domains (e.g.,\r\n" + "> > cross-NUMA scheduling domains).\r\n" + "> > \r\n" + "> > Similar issues were also observed on CPUs from other vendors during\r\n" + "> > testing, though the degree of memory bandwidth increase and other\r\n" + "> > latency effects varied. Consequently, a series of patches was developed\r\n" + "> > to address and improve these issues.\r\n" + "> > \r\n" + "> > \r\n" + "> > [Solution]\r\n" + "> > \r\n" + "> > This RFC patch series introduces the SMT_BUDDY_ASSIST scheduling\r\n" + "> > feature. The main work is as follows:\r\n" + "> > \r\n" + "> > 1. Push CFS tasks to SMT sibling CPUs during periodic load balancing.\r\n" + "> > \r\n" + "> > 2. Skip SMT-domain balancing after a successful push and avoid pulling\r\n" + "> > the pushed task back.\r\n" + "> > \r\n" + "> > 3. Restrict newidle balancing so it does not pull from higher-level\r\n" + "> > scheduling domains.\r\n" + "> > \r\n" + "> > 4. Compensate for the resulting load imbalance with a burst-task wakeup\r\n" + "> > path that sends tasks to idle CPUs.\r\n" + "> \r\n" + "> So you're combatting undue LLC migrations with brute force :-( Mostly\r\n" + "> this looks like something where cache aware scheduling should help, no?\r\n" + "> That ought to make cross-LLC migrations less attractive.\r\n" + "> \r\n" + "> Now, I realize that cache-aware scheduling as is won't help stream; when\r\n" + "> build using OpenMP the whole thing is one big process and cache-aware\r\n" + "> mostly gives up, when build using MPI its a ton of single threads and\r\n" + "> cache-aware will ignore them.\r\n" + "> \r\n" + "> Still, I think you really should look that way, perhaps investigate if\r\n" + "> something like:\r\n" + "> \r\n" + "> https://patch.msgid.link/cover.1787955777.git.tim.c.chen%40linux.intel.com\r\n" + "> \r\n" + "> can help you.\r\n" + "\r\n" + "Thank you for your suggestion. I looked at this patch series and think\r\n" + "the way it exposes the interface to users (\"always\" | \"advise\" |\r\n" + "\"never\") is quite good. We will add the related interfaces in a subsequent\r\n" + "version.\r\n" + "\r\n" + "\r\n" + "> I'm not sure why you're doing the SMT push thing; but there's this\r\n" + "> thing:\r\n" + "> \r\n" + "> https://patch.msgid.link/20261002154415.2270586-8-vincent.guittot%40linaro.org\r\n" + "\r\n" + "I previously looked at the relevant patches, and my implementation\r\n" + "approach was slightly different. Here, I mainly focused on quickly\r\n" + "distributing tasks to the SMT sibling CPUs; during this load-balancing\r\n" + "cycle I could still pull tasks, achieving faster CPU load balancing\r\n" + "(mainly for rapid local task dispersal, and it does not substantially\r\n" + " conflict with the approach in that patch). In subsequent patches, I\r\n" + "also made new considerations: checking the cfs.h_nr_runnable count and\r\n" + "no longer focusing on sleeping tasks.\r\n" + "\r\n" + "Task pushing at the SMT level is part of the overall functionality.\r\n" + "Combined with the changes in select_task_rq_fair(), it achieves rapid\r\n" + "overall task dispersal.\r\n" + "\r\n" + "Combined with the aforementioned user interface, this makes it easy to\r\n" + "enable or disable SMT-level task pushing.\r\n" + "\r\n" + "\r\n" + "thinks,\r\n" + kunyu -cb075a0aae89be45571d4a9c63992a5c87805894b373206150c5e40a53921e7c +f7cd555f0019c8a280b06d3479ac680cef64a259435b1b931aaec02f35cc4037
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.