Re: GSoC: Add SMT/HT awareness to DragonFlyBSD scheduler

[Mihai Carabas <mihai.carabas@xxxxxxxxx>]

--14dae9340eb703939604c3c74c9f
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I fixed the bugs regarding the CPU Topology on monster (here [1] you have
the cpu topology sysctl output from the monster). There were multiple
problems:
- one bug that I introduced when I did the refactoring in order to add
support for cpu topology to the vkernel
- I considered that the APICIDs are starting from 0 (in this case the
APICIDs were starting from 16)
- I considered that the APICIDs are consecutive (in this case they
weren't...because the number of cores/cpu isn't a power of two, so it had
to be skipped some ids between different physical cpus)
- I found a bug in "sbuf_vprintf". If the sbuf is auto expandable and if
there isn't enough space to put all the data, the sbuf is expanded and give
another try. The problem is that the va_list "ap" may be left in an
inconsistent state (va_arg() only iterated through some of the arguments)
and the print of the arguments would be wrong. I have made a fix, using a
copy of the "ap" [2]. (Alex H, I think this commit must go to master if I
am right).

PS: Matthew thanks a lot for the monster. You can shut it down now:). I
don't have any heuristics for core/chip cache coherence right now to do
performance testing.

[1] http://leaf.dragonflybsd.org/~mihaic/monster_cpu_topology
[2]
https://github.com/mihaicarabas/dragonfly/commit/5834c4f987284ba4f395ae701a64f3985ffc7490

--14dae9340eb703939604c3c74c9f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br><br><div>I fixed the bugs regarding the CPU Topology on monster (her=
e [1] you have the cpu topology sysctl output from the monster). There were=
 multiple problems:</div><div>- one bug that I introduced when I did the re=
factoring in order to add support for cpu topology to the vkernel</div>
<div>- I considered that the APICIDs are starting from 0 (in this case the =
APICIDs were starting from 16)</div><div>- I considered that the APICIDs ar=
e consecutive (in this case they weren&#39;t...because the number of cores/=
cpu isn&#39;t a power of two, so it had to be skipped some ids between diff=
erent physical cpus)</div>
<div>- I found a bug in &quot;sbuf_vprintf&quot;. If the sbuf is auto expan=
dable and if there isn&#39;t enough space to put all the data, the sbuf is =
expanded and give another try. The problem is that the va_list &quot;ap&quo=
t; may be left in an inconsistent state (va_arg() only iterated through som=
e of the arguments) and the print of the arguments would be wrong. I have m=
ade a fix, using a copy of the &quot;ap&quot; [2]. (Alex H, I think this co=
mmit must go to master if I am right).</div>
<div><br></div><div>PS: Matthew thanks a lot for the monster. You can shut =
it down now:). I don&#39;t have any heuristics for core/chip cache coherenc=
e right now to do performance testing.</div><div><br></div><div>[1]=A0<a hr=
ef=3D"http://leaf.dragonflybsd.org/~mihaic/monster_cpu_topology";>http://lea=
f.dragonflybsd.org/~mihaic/monster_cpu_topology</a></div>
<div>[2]=A0<a href=3D"https://github.com/mihaicarabas/dragonfly/commit/5834=
c4f987284ba4f395ae701a64f3985ffc7490">https://github.com/mihaicarabas/drago=
nfly/commit/5834c4f987284ba4f395ae701a64f3985ffc7490</a></div>

--14dae9340eb703939604c3c74c9f--