Messages in this thread | | | Date | Wed, 27 Mar 2024 11:34:54 +0530 | Subject | Re: [PATCH v3 0/2] sched: Minor changes for rd->overload access | From | Shrikanth Hegde <> |
| |
On 3/26/24 1:30 PM, Ingo Molnar wrote: > > * Shrikanth Hegde <sshegde@linux.ibm.com> wrote: > >> >> >> On 3/25/24 4:06 PM, Ingo Molnar wrote: >>> >>> * Shrikanth Hegde <sshegde@linux.ibm.com> wrote: >>> >>>> v2 -> v3: >>>> - Wrapped check for value change inside ser_rd_overload_status >>>> as suggested by Qais. >>>> - Added reviewed-by tags. >>>> >>>> v1 -> v2: >>>> - dropped Fixes tag. >>>> - Added one of the perf probes in the changelog for reference. >>>> - Added reviewed-by tags. >>>> >>>> tl;dr >>>> When running workloads in large systems, it was observed that access to >>>> rd->overload was taking time. It would be better to check the value >>>> before updating since value changes less often. Patch 1/2 does that. >>>> With patch updates happen only if necessary. CPU Bus traffic reduced a >>>> bit. No significant gains in workload performance. >>> >>> Could you please post this against the latest scheduler tree, ie. tip:sched/core? >>> >>> Thanks, >>> >>> Ingo >> >> Hi Ingo. I had mentioned the same in cover letter. Sorry if I didn't >> mention it in the correct place. >> >> *These patches depend on below to be applied first* >> https://lore.kernel.org/all/20240307085725.444486-1-sshegde@linux.ibm.com/ >> >> After that the above patch would apply.
Hi Ingo.
These two patches apply cleanly now to sched/core.
7a9dd7ef946c (HEAD -> sched/core) sched/fair: Use helper functions to access rd->overload 4f24aa918558 sched/fair: Check rd->overload value before update c829d6818b60 (origin/sched/core) sched/fair: Simplify the continue_balancing logic in sched_balance_newidle() d0f5d3cefc25 sched/fair: Introduce is_rd_overutilized() helper function to access root_domain::overutilized
> > OK, I missed that, but I don't really like patch #3 of that other series, > so we'll need to address that first. >
That will be a standalone patch now and can go later based on the discussions.
> Thanks, > > Ingo
| |