linux-kernel - sched: question on group

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <22074.1270003320@neuling.org>
Date:	Wed, 31 Mar 2010 13:42:00 +1100
From:	Michael Neuling <mikey@...ling.org>
To:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>
cc:	miltonm@....com, linux-kernel@...r.kernel.org, ego@...ibm.com
Subject: sched: question on group_capacity when SMT > 2

Peter & Ingo,

At the end of update_sg_lb_stats() we have this calculation:

  sgs->group_capacity =
		DIV_ROUND_CLOSEST(group->cpu_power, SCHED_LOAD_SCALE);

At the sibling level when we have SMT2, cpu_power will be 1178/2
(provided we are not scaling power with freq say) and SCHED_LOAD_SCALE
will be 1024, resulting in group_capacity being 1.

If we have SMT4, cpu_power will be 1178/4, hence group_capacity will end
up as 0.  Shouldn't group capacity always be >= 1?  Do we need to round
this up instead or make sure group_capacity is minimum of 1?  Or do we
need to change the way we calculate cpu_power in the SMT > 2 case? 

A similar problem could occur in SMT2 mode if cpu_power was scaled down
to less than 1024.

(FWIW the undocumented sprinkling of DIV_ROUND_blah in kernel/sched* is
somewhat disconcerting)

Regards,
Mikey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/