On 02/05/2018 10:42 PM, Joel Fernandes wrote:
On Tue, Jan 30, 2018 at 11:47 AM, Rohit Jain <rohit.k.j...@oracle.com> wrote:
[...]
@@ -6102,7 +6107,8 @@ static int select_idle_core(struct task_struct *p,
struct sched_domain *sd, int
    */
   static int select_idle_smt(struct task_struct *p, struct sched_domain
*sd, int target)
   {
-       int cpu;
+       int cpu, rcpu = -1;
+       unsigned long max_cap = 0;

          if (!static_branch_likely(&sched_smt_present))
                  return -1;
@@ -6110,11 +6116,13 @@ static int select_idle_smt(struct task_struct *p,
struct sched_domain *sd, int t
          for_each_cpu(cpu, cpu_smt_mask(target)) {
                  if (!cpumask_test_cpu(cpu, &p->cpus_allowed))
                          continue;
-               if (idle_cpu(cpu))
-                       return cpu;
+               if (idle_cpu(cpu) && (capacity_of(cpu) > max_cap)) {
+                       max_cap = capacity_of(cpu);
+                       rcpu = cpu;
At the SMT level, do you need to bother with choosing best capacity
among threads? If RT is eating into one of the SMT thread's underlying
capacity, it would eat into the other's. Wondering what's the benefit
of doing this here.

Yes, you are right because of SD_SHARE_CPUCAPACITY, however the benefit
is that if don't do this check, we might end up picking a SMT thread
which has "high" RT/IRQ activity and be on the run queue for a while,
till the pull side can bail us out.
Do your tests show a difference in results though with such change
(for select_idle_smt)?

I don't have the numbers readily available, but I did see a measurable
difference with the select_idle_smt changes.

Thanks,
Rohit


thanks,

- Joel

Reply via email to