Érdemes-e FreeBSD 8-ra frissítenem?
2009.10.05. 12:35
Igen, a válasz egyértelmű igen:
Brutálisnak tűnik, és az is:
Test | Peak performance 7.x->8.x |
MySQL OLTP RO | 1.6970x |
MySQL OLTP RW | 1.7843x |
PostgreSQL OLTP RO | 1.9257x |
PostgreSQL OLTP RW | 3.1556x |
Ha valaki azt gondolná, hogy nem normális, ha egy OS két verziója között másfél-háromszoros teljesítménykülönbség van két ilyen komplex alkalmazásban, valószínűleg igaza van. Ez azt mutatja, hogy a FreeBSD messze van még a multicore mennyországtól, de minden kiadással közelebb kerül hozzá, ahogy Kris Kennaway FreeBSD fejlesztő korábbi mérései is mutatják.
Nem is beszélve arról, hogy az akkor mért Linux sem állt éppenséggel a csúcson.
Hogy mégis mi okozza ezt a gyorsulást? A FreeBSD 8-ban már alapértelmezetten engedélyezett a superpages támogatás, aztán az ULE ütemezőn is reszeltek kicsit, amely immáron képes a CPU-k, illetve a rajtuk található cache-ek hierarchiáját is felismerni, és hasznosítani.
Sajnos ez a felismerés még messze van a tökéletestől, ugyanis a tesztgép topológiája az alap FreeBSD 8 szerint így néz ki:
kern.sched.topology_spec: <groups>
<group level="1" cache-level="0">
<cpu count="24" mask="0xffffff">0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23</cpu>
<flags></flags>
<children>
<group level="3" cache-level="2">
<cpu count="6" mask="0x3f">0, 1, 2, 3, 4, 5</cpu>
<flags></flags>
</group>
<group level="3" cache-level="2">
<cpu count="6" mask="0xfc0">6, 7, 8, 9, 10, 11</cpu>
<flags></flags>
</group>
<group level="3" cache-level="2">
<cpu count="6" mask="0x3f000">12, 13, 14, 15, 16, 17</cpu>
<flags></flags>
</group>
<group level="3" cache-level="2">
<cpu count="6" mask="0xfc0000">18, 19, 20, 21, 22, 23</cpu>
<flags></flags>
</group>
</children>
</group>
</groups>
Holott, ahogy az az alábbi képen is látható, ezen a CPU-n teljesen máshogy néz ki a cache-hierarchia:
A korrekt hierarchia felismerése végett az alábbi kernelpatch-csel bővítettem az egyelőre elég manuális listát a subr_smp.c-ben:
case 8:
/* six core, 3 dualcore parts on each package share l2. */
top = smp_topo_2level(CG_SHARE_L3, 3, CG_SHARE_L2, 2, 0);
break;
amely módosításnak köszönhetően immár megfelelően látta a kernel a topológiát:
kern.sched.topology_spec: <groups>
<group level="1" cache-level="0">
<cpu count="24" mask="0xffffff">0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23</cpu>
<flags></flags>
<children>
<group level="3" cache-level="3">
<cpu count="6" mask="0x3f">0, 1, 2, 3, 4, 5</cpu>
<flags></flags>
<children>
<group level="5" cache-level="2">
<cpu count="2" mask="0x3">0, 1</cpu>
<flags></flags>
</group>
<group level="5" cache-level="2">
<cpu count="2" mask="0xc">2, 3</cpu>
<flags></flags>
</group>
<group level="5" cache-level="2">
<cpu count="2" mask="0x30">4, 5</cpu>
<flags></flags>
</group>
</children>
</group>
<group level="3" cache-level="3">
<cpu count="6" mask="0xfc0">6, 7, 8, 9, 10, 11</cpu>
<flags></flags>
<children>
<group level="5" cache-level="2">
<cpu count="2" mask="0xc0">6, 7</cpu>
<flags></flags>
</group>
<group level="5" cache-level="2">
<cpu count="2" mask="0x300">8, 9</cpu>
<flags></flags>
</group>
<group level="5" cache-level="2">
<cpu count="2" mask="0xc00">10, 11</cpu>
<flags></flags>
</group>
</children>
</group>
<group level="3" cache-level="3">
<cpu count="6" mask="0x3f000">12, 13, 14, 15, 16, 17</cpu>
<flags></flags>
<children>
<group level="5" cache-level="2">
<cpu count="2" mask="0x3000">12, 13</cpu>
<flags></flags>
</group>
<group level="5" cache-level="2">
<cpu count="2" mask="0xc000">14, 15</cpu>
<flags></flags>
</group>
<group level="5" cache-level="2">
<cpu count="2" mask="0x30000">16, 17</cpu>
<flags></flags>
</group>
</children>
</group>
<group level="3" cache-level="3">
<cpu count="6" mask="0xfc0000">18, 19, 20, 21, 22, 23</cpu>
<flags></flags>
<children <group level="5" cache-level="2">
<cpu count="2" mask="0x300000">20, 21</cpu>
<flags></flags>
</group>
<group level="5" cache-level="2">
<cpu count="2" mask="0xc00000">22, 23</cpu>
<flags></flags>
</group>
</children>
</group>
</children>
</group>
</groups>
Sajnos azonban van még mit faragni az ütemezőn, mert jól látszik, hogy nem bírja ellátni munkával ezt a gépet, amely erősen kihat a rá futó alkalmazások teljesítményére...
A bejegyzés trackback címe:
Kommentek:
A hozzászólások a vonatkozó jogszabályok értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a Felhasználási feltételekben és az adatvédelmi tájékoztatóban.