Linux és szimmetrikus többprocesszoros rendszer (forráskód) - szoftver termékek
M. Tim Jones, tanácsadó mérnök, Emulex
A Linux rendszer sebessége sokféleképpen növelhető, és az egyik legnépszerűbb a processzor teljesítményének növelése. A nyilvánvaló megoldás az, ha nagyobb processzorú processzort használunk, de bármely technológia esetében fizikai korlátozás van, amikor az óragenerátor egyszerűen nem tud gyorsabban dolgozni. Ha eléred ezt a korlátot, sokkal jobb megközelítést alkalmazhatsz, és több processzort is használhatsz. Sajnos a teljesítmény nemlineáris függést mutat az egyes processzorok paramétereinek készletétől.
A Linux többprocesszoros használatának megvitatása előtt nézzük meg a történetét.
Többprocesszoros történelem
A Flynn többprocesszoros architektúrájának osztályozása.
Egy adatfolyam, egy adatfolyam (SISD - Egyutas utasítás, Egyedi adatok) tipikus egyprocesszoros architektúra. Többprocesszoros architektúra Sok adatfolyam, több adatfolyam (MIMD) tartalmaz különálló processzorokat, amelyek független adatokon működnek (párhuzamos vezérlés). Végül, egy utasításfolyam, számos adatfolyam (SIMD - Egyutas utasítás, Több adat) számos processzorral rendelkezik, amelyek különböző típusú adatokkal működnek (adat párhuzamosság).
A többszörös feldolgozás az 1950-es évek közepén született számos vállalatnál, amelyek közül néhányan tudják, és egyesek már elfelejtettek (IBM, Digital Equipment Corporation, Control Data Corporation). A korai 1960-as években, Burroughs Corporation bemutatta a szimmetrikus többprocesszoros MIMD típusú négy CPU, legfeljebb tizenhat memóriamodulok csatlakozik a koordináta-csatlakozó (első SMP architektúra). A széles körben ismert és sikeres CDC 6600-at 1964-ben vezették be, és tíz alprocesszorral (perifériás processzorral) ellátták a CPU-t. A hatvanas évek végén a Honeywell kiadta a nyolc CPU Multics szimmetrikus többprocesszoros rendszert.
Miközben többprocesszoros rendszerek alakultak ki, a technológiák is előre haladtak, csökkentve a processzorok méretét és növelték a képességüket arra, hogy jelentősen magasabb órajelet használjanak. Az 1980-as években olyan vállalatok, mint a Cray Research, többprocesszoros rendszereket és UNIX®-szerű operációs rendszereket vezettek be, amelyek felhasználhatják őket (CX-OS).
Az 1980-as évek végén az egyprocesszoros személyi számítógépek, mint például az IBM PC népszerűsége miatt a többprocesszoros rendszerek csökkentek. De most, húsz évvel később, a többszörös feldolgozás ugyanazon személyi számítógépekre visszatért szimmetrikus többprocesszoros formában.
Gene Amdahl (Gene Amdahl), egy számítógépes tervező és az IBM munkatársa kifejlesztett számítógép architektúrák IBM, létrehozta a névadó cég, Amdahl Corporation és mások. De hírnevet hozott neki törvényt, amely kiszámítja a lehető legnagyobb javulás a rendszer, miközben javítja annak részei. A törvényt elsősorban a rendszer teljesítményének maximális elméleti javulásának kiszámításához használják több processzor használatakor (lásd 1. ábra).
1. ábra: Amdahl törvény a folyamat párhuzamosítására
Az egyenlet az 1. ábrán látható, akkor lehet számolni a maximális javulás a rendszer teljesítményét, n processzorral és F. tényező, amely azt jelzi, mely része a rendszer nem lehet párhuzamosított (része rendszer, amely összhangban áll a természetben). Az eredmény a 2. ábrán látható.
2. ábra: Amdahl-törvény a legfeljebb tíz processzorral rendelkező rendszerre
A 2. ábra felső sorában a processzorok száma látható. Ideális esetben ezt szeretné látni, miután további processzorokat adtak hozzá a probléma megoldásához. Sajnos az a tény, hogy nem minden a feladatban párhuzamos lehet, és a processzorok kezelésében nem termelnek költségeket, a gyorsulás valamivel kisebb. Az alábbiakban (lila vonal) olyan probléma van, amely 90% -ban konzisztens. A diagramon a legjobb példa a barna vonalnak felel meg, amely 10% -os következetességet és ezzel párhuzamosan 90% -os feladatot jelent. Még ebben az esetben is tíz processzor nem sokkal jobb, mint öt.
Többprocesszoros és PC
Az SMP architektúra egyike azoknak, ahol két vagy több azonos processzor van összekötve egymással megosztott memórián keresztül. Mindegyikük ugyanolyan hozzáférést biztosít a megosztott memóriához (ugyanúgy, amikor a memóriahelyre való várakozás). Ennek ellentéte a nem egységes memória hozzáférés (NUMA - Non-Uniform Memory Access) architektúrája. Például minden processzornak van saját memóriája és hozzáférése a különböző késleltetésű megosztott memóriához.
Lazán összekapcsolt többprocesszoros
Korai SMP Linux rendszerek lazán csatolt többprocesszoros rendszerek, mely különböző különálló kapcsolódó rendszerek nagy sebességű összekapcsolása (például a 10G Ethernet, Fibre Channel vagy Infiniband). Az architektúra másik neve a fürt (lásd a 3. ábrát), amelyhez a Linux Beowulf projekt népszerű megoldás marad. A Linux Beowulf klaszterek a rendelkezésre álló hardverekből és hagyományos hálózati kapcsolatokból, például Ethernet-ből építhetők.
3. ábra Lazán kapcsolt többprocesszoros architektúra
A laza csatolású többprocesszoros architektúra építési rendszerei egyszerűek (a Beowulf-hoz hasonló projekteknek köszönhetően), de korlátozottsága van. A nagy többprocesszoros hálózat létrehozása jelentős kapacitást és helyet igényelhet. Súlyosabb akadály a kommunikációs csatorna anyaga. Még egy nagysebességű hálózaton, például 10G Ethernet esetén is létezik skálázhatósági határ a rendszer számára.
Erősen összekapcsolt többprocesszoros
A erősen összekapcsolt többprocesszoros feldolgozás a chip szintjén (CMP - chip szintű multiprocessing) történik. Képzeljünk el egy lazán csatolt építészetet, amely a kristály szintjére csökkent. Ez az ötlet a szorosan összekapcsolt multiprocessing (más néven multi-core computing). Egy integrált mikroáramkörön több kristály, megosztott memória és kapcsolat képezi a jól integrált magot a multiprocesszorhoz (lásd a 4. ábrát).
Aszimmetrikus többprocesszoros (ASMP - Asymmetric multiprocessing), kilenc CPU
Annak érdekében, hogy a SMP-t SMP-kompatibilis eszközökkel használhassa Linuxon, helyesen kell beállítania a rendszermagot. A CONFIG_SMP opciót engedélyezni kell a rendszermag konfiguráció során, hogy a rendszermag tudjon SMP-ről. Ha egy ilyen rendszermag többprocesszoros állomáson fut, akkor a proc fájlrendszer segítségével meghatározhatja a processzorok számát és típusát.
Először a processzorok számát kapja meg a / proc fájlban található cpuinfo fájlból a grep használatával. Amint az 1. listából láthatja, a szövegprocesszorral kezdődő karakterláncok számláló opcióját (-c) használja. A cpuinfo fájl tartalma is szerepel. Például a Xeon alaplapot két kristályon veszik fel.
Listázás 1. A proc fájlrendszer használatával információt kaphat a CPU-ról
A Linux 2.0 első bevezetése után az SMP támogatás egy alapvető zárolási rendszerből állt, amely a rendszerben való szekvenált hozzáférést eredményezte. Később, kevés előrehaladás történt az SMP támogatásában, de csak a 2.6-os rendszermaggal, az SMP teljes ereje végre megjelent.
A 2.6-es kernel új 0 (1) ütemezőt vezetett be, amely jobb támogatást nyújtott az SMP-rendszerek számára. A kulcs az volt, hogy képes legyen kiegyensúlyozni a terhelést az összes rendelkezésre álló processzoron, amennyire lehetséges, elkerülve a processzorok közötti váltási folyamatokat a gyorsítótár hatékonyabb használatához. A gyorsítótár teljesítményét illetően emlékezzetek vissza a 4. ábrából, hogy amikor egy feladat egy CPU-val kölcsönhatásba kerül, a másikba történő áthelyezéshez gyorsítótár-beavatkozást igényel. Ez növeli a várakozási időt a feladat memóriájának eléréséhez, miközben adatai az új CPU gyorsítótárában vannak.
SMP a magban
Annak megértéséhez, hogy az SMP inicializálása egy adott architektúrára vonatkozóan, nézze meg az smp.c vagy smpboot.c fájlokat a rendszermagban. / linux / arch /
A 2.6-os rendszernek minden egyes processzorra (lefutott és aktív sorozathoz) futópárat kell mentenie. Mindegyik sorozatban 140 prioritás támogatható, amelyek közül 100 valós idejű feladatokhoz, a fennmaradó 40 pedig a felhasználói feladatokhoz. A feladatoknak időt kell adniuk a végrehajtásnak, és amikor használják az idejüket, akkor az aktív sorozattól a lejártig mozognak. Ily módon a CPU mindegyikhez hasonlóan hozzáférhetõ (csak az egyes CPU-k bezárása).
A feladatok sorában minden egyes CPU esetében a munka kiegyensúlyozható, így a rendszer összes processzorának súlyozott terhelését biztosítja. Minden 200 ezredmásodpercben az ütemező terheléskiegyenlítést hajt végre a feladatok újraelosztása és az egyensúly fenntartása érdekében.
A felhasználói térforgalom: az SMP erejének fejlesztése
A Linux kernelben sok munkát végeztek az SMP fejlesztése érdekében, de az operációs rendszer önmagában nem elegendő. Emlékezzünk vissza, hogy az SMP ereje TLP-ben rejlik. Az egyes monolitikus (egyszálas) programok nem használhatják a SMP-t, de az SMP-t olyan programokban használhatják, amelyek sok szálból állnak, amelyek a magok között oszthatók meg. Míg egy szál vár egy I / O műveletet, a másik hasznos munkát végezhet. Így a szálak működnek, egymást átfedve a várakozási időt.
A hordozható operációs rendszer interfész (POSIX) streamek kiváló módja annak, hogy olyan menetes alkalmazásokat készítsenek, amelyek képesek SMP-t használni. A POSIX szabvány áramlása mechanizmust biztosít a szálak kezelésére, valamint a megosztott memóriára. A program aktiválásakor számos szálat hoz létre, amelyek mindegyike fenntartja saját veremét (helyi változók és állapot), de osztja a szülő adatterületét. Az összes létrehozott szál ugyanazt az adatot tartalmazza, de itt a probléma.
A megosztott memória többszálú hozzáférésének támogatásához koordinációs mechanizmusokra van szükség. A POSIX kölcsönös kizárási funkciót biztosít a kritikus szakaszok létrehozásához. amelyek egyetlen objektumhoz kizárólagos hozzáférést biztosítanak egy objektumhoz (memóriahelyhez). Ha ez nem történik meg, a memória megsérülhet, ha nem szinkronizált műveleteket hajt végre több szál. A 2. lista egy kritikus szakasz létrehozását szemlélteti a POSIX kölcsönös kirekesztés segítségével.
Listázás 2. A pthread_mutex_lock használata és feloldása kritikus szakaszok létrehozásához
Ha több szál megpróbálja lezárni a szemaforát a kezdeti hívás után a tetején, blokkolva van, és kéréseik sorban állnak, amíg a pthread_mutex_unlock hívás végrehajtásra kerül.
A rendszermag változó védelme az SMP számára
Ha a processzor több magja párhuzamosan működik az operációs rendszermag számára, kívánatos elkerülni a processzor magjával kapcsolatos adatok megosztását. Ezért a 2.6 rendszermag bevezette az egyes rendszermagokhoz tartozó változók fogalmát, amelyek az egyes CPU-khoz kapcsolódnak. Ez lehetővé teszi a CPU számára leggyakrabban használt változók deklarálását, ami minimalizálja a blokkolási követelményeket és javítja a végrehajtást.
Az egyedi kernel változóinak meghatározása a DEFINE_PER_CPU makró segítségével történik. amelyhez a változó típusát és nevét adja meg. Mivel a makró l-értékként jön be, itt be tudod kezdeni. A következő példa (./arch/i386/kernel/smpboot.c) meghatározza az egyes CPU-k állapotát jelző változót a rendszerben.
A makrók egy változót hoznak létre, egy a CPU egyes példányaira. Egy külön CPU változójának megszerzéséhez a per_cpu makrót az smp_processor_id függvénnyel együtt kell használni. amely visszaadja az aktuális CPU azonosítót, amelyhez a program jelenleg fut.
A rendszermag más funkciókat biztosít az egyes CPU lezárásához és a változók dinamikus elosztásához. Ezek a funkciók megtalálhatók a ./include/linux/percpu.h címen.
Amikor a processzor frekvenciája eléri a határértéket, több processzort adnak hozzá a teljesítmény növeléséhez. Korábban ez azt jelentette, hogy több processzort adtak hozzá az alaplaphoz, vagy több független számítógépet klaszterbe csoportosítottak. Ma a kristályszintű többprocesszoros processzor több processzort biztosít egyetlen chipen, így még gyorsabb teljesítményt nyújt a memória várakozási idejének csökkentésével.
SMP rendszerek nem csak a kiszolgálókon, hanem az asztali gépeken is megtalálhatók, különösen a virtualizáció bevezetésével. Mint sok fejlett technológia, a Linux támogatást nyújt az SMP számára. A rendszermag a rendelkezésre álló CPU-ok (a szálaktól a virtuális operációs rendszerekig) terhelését optimalizálja. Mindössze annyit kell meggyőződni arról, hogy az alkalmazás megfelelően fel van osztva szálakra, hogy az SMP erejét használja.