(12) Oversettelse av europeisk patentskrift - Patentstyret

(12) Oversettelse av 

europeisk patentskrift 

(19) NO 

NORGE (51) Int Cl. 

G06F 9/50 (2006.01) 

G06F 9/30 (2006.01) 

G06F 9/455 (2006.01) 

Patentstyret 

(21) Oversettelse publisert 2011.11.14 

(80) Dato for Den Europeiske 

Patentmyndighets 

publisering av det meddelte 

patentet: 2011.06.22 

(86) Europeisk søknadsnr: 09701347.8 

(86) Europeisk innleveringsdag 2009.01.12 

(87) Den europeiske søknadens 

Publiseringsdato 2010.09.01 

(30) Prioritet 2008.01.11 US 972802 

(11) NO/EP 2223214 B1 

(84) Utpekte stater AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC 

MK MT NL NO PL PT RO SE SI SK TR 

(62) Avdelt fra 10184363.9 / 2 290 539 

(73) Innehaver International Business Machines Corporation, New Orchard RoadArmonk, NY 

10504, USA 

(72) Oppfinner GAINEY JR., Charles, 21 James StreetPoughkeepsieNew York 12603-1524, USA 

FARRELL, Mark, 38 Stirrup LanePleasant ValleyNew York 12569, USA 

KUBALA, Jeffrey, 10 Morgan LanePoughquagNew York 12570, USA 

SCHMIDT, Donald, 77 Vincent LaneStone RidgeNew York 12484, USA 

(74) Fullmektig Oslo Patentkontor AS, Postboks 7007 Majorstua , 0306 OSLO, Norge 

(54) Benevnelse Oppdagelse av virtuell topologikonfigurasjon til en datamaskin 

(56) Anførte 

publikasjoner EP-A- 0 730 226 B1, US-A1- 2007 203 943 B1, EP-A- 1 674 987 B1

5 

10 

15 

20 

25 

30 

Teknisk felt 

Den foreliggende oppfinnelsen relaterer seg hovedsakelig til en virtualisering av 

1 

multiprosessor systemer. Spesielt, den foreliggende oppfinnelsen relaterer seg til å 

gjøre det mulig for programmer å oppdage topologien av deres virtuelle miljø. 

Bakgrunn for oppfinnelsen 

Blant systemkontrollfunksjonene er det muligheten til dele systemet inn i flere lo- 

giske deler (LPAR’er). En LPAR er en underliggende del av prosessormaskinvaren 

som er definert til å støtte et operativsystem. En LPAR inneholder resurser (proses- 

sorer, minne, og I/O-enheter) og opererer som et uavhengig system. Multiple lo- 

giske inndelinger kan eksistere innen en stormaskins maskinvaresystem. 

I stormaskindatasystemet fra IBM inkluderende S/390®, var det i mange år en 

begrensning på 15 LPAR’er. Nyere maskiner har 30 (og potensielt flere). Slike 

maskiner er eksemplifisert av de av z/Architecture®. IBM® z/Architecture® er 

beskrevet i operasjonsmanualen til z/Architecture SA22-7832-05 publisert April 

2007 av IBM. 

Praktiske begrensninger av størrelsen på minnet, I/O tilgjengelighet og tilgjengelig 

prosesseringskraft begrenser vanligvis antallet LPAR’er til mindre enn disse maksi- 

ma 

Maskinvare’en og fastvare’en som skaffer til veie inndelingen er kjent som PR/SM 

(Prosessorresurser/ Systemadministrator). Det er PR/SM funksjoner som er vant til 

å lage og kjøre LPAR’er. Denne forskjellen mellom PR/SM (en innbygget fasilitet) og 

LPAR’er (resultatet av bruken av PR/SM) er ofte ignorert og termen LPAR er kollek- 

tivt brukt for fasiliteten og dens resultater. 

Systemadministratorer tilegner deler av minnet til hver LPAR og minnet kan ikke bli 

delt imellom LPAR’er. Administratorene kan tilegne prosessorene (også kjent som 

CP’er eller CPU’er) til spesifikke LPAR’er eller de kan tillate systemkontrollerene å 

ekspedere hvilke som helst eller alle prosessorene til alle LPAR’ene ved å bruke en 

intern lastbalanserende algoritme. Kanalene (CHPID’er) kan bli tilegnet til spesifikke 

LPAR’er eller kan bli delt ved multiple LPAR’er, avhengig av enhetene i hver kanal. 

Et system med en enkelt prosessor (CP prosessor) kan ha multiple LPAR’er. PR/SM 

har en intern fordelingssentral som kan allokere en del av prosessorene til hver

5 

10 

15 

20 

25 

30 

LPAR, mye likt hvordan et operativsystem fordeler en del av sin prosessortid til 

hver prosess, tråd eller oppgave. 

2 

Å dele kontrollspesifikasjoner er delvis rommet i IOCD’ene og er delvis rommet i en 

systemprofil. IOCD’ene og profilene befinner seg begge i støtteelementet (SE) som 

ganske enkelt er en bærbar datamaskin inne i systemet. SE’en kan bli koblet til en 

eller flere Maskinvare Management Consoles (HMC’er), som er skrivebords-PC’er 

brukt til å overvåke og kontrollere maskinvare slik som mikroprosessorene til 

stormaskinene. En HMC er mer beleilig å bruke enn en SE og kan kontrollere et 

flertall av stormaskiner. 

Å arbeide fra en HMC (eller fra en SE, i uvanlige forhold), en operatør forbereder en 

stormaskin for bruk ved valg og lasting av en profil og en IOCDS. Denne lager 

LPAR’er og konfigurerer kanalene med enhetsnumre, LPAR-oppgaver, multippel sti- 

informasjon, og så videre. Dette er kjent som en Power – på Reset (POR). Ved å 

laste en annen profil og IOCDS, operatøren kan fullstendig forandre antallet og 

naturen til LPAR’er og fremtoningen til I/O-configurasjonen. Imidlertid ved å gjøre 

dette forstyrres det operativsystemet og applikasjonene som er i bruk og er derfor 

sjelden utført uten nøye planlegging. 

Logisk oppdeling (LPAR’er) er, i praksis, lik separate hovedmaskiner. 

Hver LPAR kjører sitt eget operativsystem. Dette kan være hvilke som helst opera- 

tiv system for en stormaskin; det er ingen grunn til å kjøre z/OS®, f.eks. i hver 

LPAR. Installeringsplanleggerene kan velge å dele I/O enheten på flere LPAR’er, 

men dette er et lokalt valg. 

Systemadministratoren kan tillegne en eller flere systemprosessorer for den inklu- 

sive bruken av en LPAR. Alternativt, kan administratoren tillate alle prosessene til å 

bli brukt på enkelte eller alle LPAR’een. Her skaffer systemkontrollfunksjonene (ofte 

kjent som microcode eller fastvare) til veie en avsender for å dele prosessorene 

blant de valgte LPAR’ene. Administratoren kan spesifisere et maksimum antall av 

samtidige prosessorer som utføres i hver LPAR. Administratoren kan også skaffe til 

veie vekting for forskjellige LPAR’er; for eksempel, spesifisere at LPAR 1 skulle mot- 

ta dobbelt så masse prosessortid som LPAR2. 

Operativsystemet i hver LPAR er IPL’et separat, har sin egen kopi av sitt operativ- 

system, har sin egen operatørkonsoll (hvis nødvendig), og så videre. Hvis systemet 

i en LPAR krasjer, har det ingen effekt på de andre LPAR’ene.

5 

10 

15 

20 

25 

30 

3 

I en stormaskin med tre LPAR’er, f.eks., kan du ha en produksjon z/OS i LPAR1, en 

testversjon av z/OS i LPAR2, og Linux® for S/390® i LPAR3. Hvis dette totale sys- 

temet har 8 GB med minne, kan vi kanskje ha tillegnet 4 GB til LPAR1, 1 GB til 

LPAR2, 1 GB til LPAR3 og 2GB i reserve. Operativsystemkonsollene for de to z/OS 

LPAR’ene kan være på fullstendig forskjellige steder. 

For de fleste praktiske formålene er det ikke noe forskjell mellom, f.eks., tre sepa- 

rate stormaskiner som kjører z/OS (og deler det meste av deres I/O konfigurasjon) 

og tre LPAR’er på den samme stormaskinen som gjør den samme tingen. Med 

mindre unntak kan ikke z/OS, operatørene, og applikasjonene detektere forskjellen. 

De mindre forskjellene inkluderer mulighetene ved z/OS (hvis tillatt når LPAR’ene 

er definert) til å skaffe til veie prestasjons- og utnyttelsesinformasjon, over hele 

stormaskinsystemet og for dynamisk flytte resurser (prosessorer og kanaler) lange 

LPAR’ene for å bedre prestasjonene. 

Nåværende IBM® stormaskiner har et sentralt prosessorkompleks (CPC), som kan 

inneholde flere forskjellige typer av z/Architecture® prosessorer som kan bli brukt 

for litt forskjellige formål. 

Flere av disse formålene er relatert til kostnadskontroll av programvare, mens and- 

re er mer fundamentale. Alle av disse prosessorene i CPC’en begynner som ekviva- 

lente prosessorenheter (PU’er) eller motorer som ikke har blitt karakterisert for 

bruk. Hver prosessor er karakterisert av IBM under installering eller ved en senere 

tid. De potensielle karakteriseringene er: 

- Prosessor (CP) 

Denne prosessortypen er tilgjengelig for normale operativsystemer og 

applikasjonsprogramvare. 

- Systemassisterende prosessor (SAP) 

hver moderne stormaskin har i det minste en SAP; større systemer har 

flere. SAP’en iverksetter interne koder for å forsyne I/O undersystemet. 

En SAP, for eksempel, oversetter enhetsnumre og virkelige adresser til 

kanalstiidentifiserere (CHPID’er), kontrollenhetsadresser, og enhetsnum- 

re. Det håndterer multiple stier til kontrollenheter og utfører feilgjenopp-

5 

10 

15 

20 

25 

30 

4 

retting for midlertidige feil. Operativsystemet og applikasjonene kan ikke 

detektere SAP’er og SAP’er bruker ikke “normalt" minne. 

- Integrert fasilitet for Linux® (IFL) 

- zAAP 

- zIIP 

dette er en normal prosessor med en eller to instruksjoner utkoblede 

som er brukt bare ved hjelp av z/OS®. Linux bruker ikke disse instruk- 

sjonene og kan bli utført ved hjelp av en IFL. Linux kan bli utført av en 

CP i tillegg. Forskjellene er at en IFL ikke er tellet når man spesifiserer 

modellnummeret til systemet. Dette kan føre til en vesentlig forskjell i 

programvare kostnader. 

dette er en prosessor med et antall av funksjoner deaktivert (avbrudds- 

håndtering, enkelte instruksjoner) slik at intet fult operativsystem kan bli 

effektuert på prosessoren. Imidlertid, z/OS kan detektere nærværet av 

zAAP prosessorer og vil bruke de til å utføre Java code. Den samme 

Javakoden kan bli effektuert på en standard CP. Igjen, er zAAPmotoren 

ikke tellet når man spesifiserer modellen til systemet. I likhet med IFL’er, 

eksisterer de kun for å kontrollere programvare kostnader. 

Systemet z9 Integrert informasjonsprosessor (Integrated Information 

Processor) (zIIP) er en spesialisert motor for prosessering av passende 

arbeidslaster for databaser. zIIP’ene er designet for å hjelpe med å sen- 

ke programvarekostnadene for valgte arbeidslaster på stormaskinen, slik 

som business intelligens (business intelligence) (BI), enterprice resource 

planning (ERP) og customer relationship management (CRM). zIIP’en 

styrker stormaskinens rolle som en datahub til bedriften ved å hjelpe 

med å gjøre direkte tilgang til DB2® mer kostnadseffektiv og redusere 

behovet for multiple kopier av data. 

Integrert koblingsfasilitet (ICF) 

Disse prosessorene kjører bare lisensiert intern kode. De er ikke synlige for normale 

operativsystemer eller applikasjoner. En koplingsfasilitet er, egentlig en stor minne

5 

10 

15 

20 

25 

30 

notisblokk brukt av multiple systemer for å koordinere arbeid. ICF’er må bli dedi- 

kert til LPAR’er som så blir koblingsfasiliter. 

Reserve 

En ukarakterisert PU virker som en “reserve” hvis systemkontrollerene detekterer 

en feilende CP eller SAP, den kan bli byttet ut med en reserve PU. I fleste tilfeller 

kan dette bli gjort uten noe systemavbrudd, selv for applikasjonen som kjører på 

den feilende prosessoren. 

I tillegg til disse karakteriseringene av prosessorer, har enkelte stormaskiner mo- 

5 

deller eller versjoner som er konfigurert til å kjøre saktere enn den potensielle has- 

tigheten til deres CP’er. Dette er vidt kjent som “underklokking” (knee-capping), 

selv om IBM foretrekker terminologien kapasitetssetting eller noe liknende. Det er 

gjort ved å bruke mikrokoder for sette inn nullsykluser i instruksjonsstrømmen til 

prosessoren. Formålet, igjen, er for å kontrollere programvarekostnadene ved å ha 

den minste stormaskinmodellen eller versjonen som møter applikasjonskravene. 

IFL’er, SAP’er, zAAP’er, zIIP’er, og ICF’er virker alltid ved full hastighet på prosesso- 

ren fordi disse prosessorene “teller ikke“ i beregninger av prisen på programvare. 

Prosessor og CPU kan referere til enten den komplette systemboksen, eller til en av 

prosessorene (CPU’ene) i systemboksen. Selv om meningen kan være klar utfra 

sammenhengen av diskusjonen. IBM bruker terminologien sentral prosessor 

komplex (central prosessor complex) (CPC) for å referere til den fysiske samlingen 

av maskinvare som inkluderer hovedlageret, en eller flere av sentralprosessorene, 

taktgivere, og kanaler. (Noen systemprogrammerere bruker terminologien sentral 

elektronisk kompleks (central electronic complex) (CEC) for å referere til storma- 

skinen “boks”, men den foretrukne terminologien er CPC.) 

Kort fortalt alle S/390 eller z/Architecture prosessorene i en CPC er prosesserings- 

enhetene (PU’er). Når IBM leverer CPC’en, er PU’ene karakterisert som CP’er (for 

normalt arbeid), integrert fasilitet for Linux (IFL), integrert koplingsfasilitet (ICF) for 

parallell sysplex konfigureringer, og så videre. 

Profesjonelle på stormaskiner bruker typisk systemer for å indikere at maskinvare- 

bokser, et komplett maskinvare miljø (med I/O enhet), eller et driftsmiljø (med 

programvare), avhengig av sammenhengen. Den typiske bruken av prosessoren for 

å midle en enkelt prosessor (CP) i CPC’en.

5 

10 

15 

20 

25 

30 

6 

z/VM® HYPERVISOR er designet for å hjelpe klienter med å utvide businessverdi- 

en av stormaskinteknologien over hele foretaket ved å integrere applikasjoner og 

data mens å forsyne uvanlige nivåer av tilgjengelighet, sikkerhet og enkel drifting. 

z/VM viritualiseringsteknikk er designet til å tillate muligheten for klienter å kjøre 

fra hundrer til tusener av Linux servere på en enkelt stormaskin som kjører med 

andre System z operativsystemer, slik som z/OS®, eller som en storskala server- 

løsning for et foretak som kun kjører Linux. z/VM V5.3 kan også hjelpe til med å 

forbedre produktiviteten ved å være vert for ikke-Linux arbeidslaster slik som z/OS, 

z/VSE, og z/TPF. 

z/VM forsyner hver bruker med et individuelt arbeidsmiljø kjent som en virtuell ma- 

skin. Den virtuelle maskinen simulerer eksistensen av en dedikert virkelig maskin, 

inkluderende prosessorfunksjoner, minner, nettverk, og input/output (I/O) resur- 

ser. Operativsystemer og applikasjonsprogrammer kan kjøre i virtuelle maskiner 

som gjester. For eksempel, kan du kjøre multiple Linux og z/OS bilder og det sam- 

me z/VM systemet som også støtter forskjellige applikasjoner og endebrukere. Som 

et resultat kan, utvikling, testing, og produksjonsmiljøer dele en enkelt fysisk da- 

tamaskin. 

Med referanse til figurene 15A-15D, involverer partisjonering og virtualisering et 

skifte i tankegangen fra fysisk til psykisk ved å behandle IT resurser som logiske 

ansamlinger i stedet for separate fysiske entiteter. Dette involverer konsolidering 

og ansamling av IT-resurser, og forsyne en «illusjon av et enkelt system» for både 

homogene og heterogene servere, lagre, distribuerte systemer, og nettverk. 

Partisjonering av maskinvare involverer separate CPU’er for separate operativsys- 

temer, hver av hvilke kjører sine spesifikke applikasjoner. Programvarepartisjone- 

ring tar i bruk en programvare basert forvalter av virtuelle maskiner (hypervisor) til 

å muliggjøre individuelle operativsystemer til å kjøre på hvilke som helst eller alle 

av CPU’ene. 

Programvare basert forvaltere av virtuelle maskiner tillater multiple operativsyste- 

mer å kjøre på en vertsmaskin på den samme tiden. Teknologien til programvare 

baserte forvaltere av virtuelle maskiner som har sitt opphav i IBM VM/370, for- 

gjengeren til z/VM vi har i dag. Logisk partisjonering (LPAR) involverer patisjone- 

ringsfastvare (en maskinvarebasert hypervisor) for å isolere operativsystemet fra 

CPU’ene.

5 

10 

15 

20 

25 

30 

Virtualiseringen muliggjør eller utnytter fire fundamentale kapasiteter: ressursde- 

7 

ling, ressursansamling, kappestrid av funksjoner, isolering. Vi utforsker disse tema- 

ene i ytterligere detalj i den følgende seksjonen. 

z/VM er et operativsystem for IBM System z plattformen som forsyner en høyst 

fleksibel test og produksjonsmiljø. z/VM implementeringen av IBM viritualise- 

ringsteknologien tilveiebringer muligheten til å kjøre fullfunksjons operativsystemer 

slik som Linux på system z, z/OS og andre som «gjester» av z/VM. z/VM støtter 64- 

bits IBM z/Arkitektur gjester og 31-bits IBM Enterprise Systems Architecture /390 

gjester. 

z/VM anskaffer hver b ruker med et individuelt arbeidsmiljø kjent som en virtuell 

maskin. Den virituelle maskinen simulerer eksistensen til en dedikert reell maskin, 

inkluderende prosessorfunksjoner, minne, netverk, g input/output (I/O) resurser. 

Operativsystemer og applikasjonsprogrammer kan kjøre i virituelle maskiner som 

gjester. For eksempel, kan man kjøre multiple Linux og z/OS® bilder på den sam- 

me z/VM systemer som også støtter forskjellige applikasjoner og endebrukere. Som 

et resultat, utvikling, testing, og produksjonsmiljøer kan dele en enkelt fysisk da- 

tamaskin. 

En virituell maskin bruker virkelige maskinvareresurser, men selv med dedikerte 

enheter (som et bånddrev), den virituelle adressen til bånddrevet kan eller kan ikke 

være den samme som den reelle adressen til bånddrevet. Derfor, kjenner bare en 

virituell maskin «virituell maskinvare» som kan eksistere eller ikke eksistere i den 

reelle verdenen. 

Et første-nivå z/VM er grunnoperativsystemet som er installert på toppen av den 

virkelige maskinvaren fig. 16. Et nivå-to operativsystem er et system som er laget 

på et z/VM baseoperativsystem. Derfor z/VM som et baseoperativsystem kjører på 

maskinvaren, mens et gjesteoperativsystem kjører på viritualiseringsteknologien. I 

figur 14 illustreres en nivå-to gjest z/VM OS lastet inn i en nivå-en gjest (gjest-1) 

cpartisjon. 

Med andre ord, er det et nivå-en z/VM operativsystem som passer direkte med ma- 

skinvaren, men gjesten av dette nivå-en z/VM system er viritualisert. Ved virituali- 

sering av maskinvaren til gjesten, har vi muligheten til å lage og bruke så mange 

gjester som muligsom nødvendig med en liten mengde med maskinvare.

5 

10 

15 

20 

25 

30 

8 

Som tidligere nevnt, er operativsystemet som kjører på en virituell maskin ofte kalt 

«gjester». Andre terminologier og fraser som man kan støte på er: 

- «kjøre første nivå» midler kjører direkte på maskinvaren (som er hva z/VM 

gjør). 

- «kjøre andre nivå», «kjøre under VM», eller «kjøre på (toppen av) VM» be- 

tyr å kjøre som en gjest. 

Et eksempel på funksjonaliteten til z/VM er, hvis du har et nivå-en z/VM system og 

et nivå-to z/VM system, , unne man fortsette å lage flere operativsystemer på nivå- 

2 systemet. Denne typen av miljø er spesielt brukbart for testing av operativsyste- 

mer installert før det er satt i bruk, eller for testing eler debugging av operativsys- 

temet. Virituelle resurser kan ha funksjoner for trekk som ikke er tilgjengelige i 

deres underliggende fysiske resurser. Figur 14 illustrerer viritualisering ved res- 

sursemulering. 

Eksempler inkluderer arkitekturemuleringsprogramvare som implementerer en pro- 

sessors arkitektur ved bruk av en annen; iSCSI, som implementerer en virtuell 

SCSI bus på et IP nettverk; og virituell båndlagring implementert på det fysiske 

disklageret. 

Videre, er pakkingen av prosessorenheter (CPU’er) i moderne teknologi ofte hierar- 

kisk. Multiple kjerner kan bli plassert på en enkelt krets, multiple kretser kan bli 

plassert i en enkelt modul. Multiple moduler kan bli pakket på et brett ofte referert 

til som en bok, og multiple bøker være distribuert over multiple rammer. 

CPU’er har ofte flere nivåer med cache, for eksempel kan hver prosessor ha en ca- 

che (eller muliggens en delt instruksjonscache og en datacache) og det kan i tillegg 

være større cacher imellom hver prosessor og hovedminnegrensesnittet. Avhengig 

av nivået til hierarkiet, er cache også plassert for å forbedre den samlede ytelsen, 

og på bestemte nivåer kan cache være delt mellom fler enn en enkelt CPU. Engi- 

neeringsavgjørelsene med hensyn på slik plassering tar for seg plass, 

kraft/temperatur, kablingsdistanse, CPU-frekvens, systemytelse og andre aspekter. 

Denne plasseringen av elementer til CPU’en lager en intern struktur som kan være 

mer eller mindre favoriserende for en bestemt logisk avdeling, avhengig av hvor 

plasseringen av hver CPU av partisjoneringen befinner seg. En logisk partisjonering 

gir inntrykket av at et operativsystem, med eierskap av enkelte resurser inkluderer 

prosessorbruk hvor faktisk, operativsystemet deler resursene med andre operativ-

5 

10 

15 

20 

25 

30 

9 

systemer i andre partisjoner. Normalt, er programvare ikke klar over plasseringen 

og, i en symmetrisk multiprosessering (SMP) konfigurasjon, observeres et sett med 

CPU’er hvor hver forsyner det samme nivået med ytelse. Problemet er at ignorering 

av pakking og distansen mellom hvilke som helst to CPU’er kan resultere i at pro- 

gramvaretar mindre enn optimale beslutninger hvordan CPU’er kan bli tillegnet ar- 

beid. Derfor er ikke det fulle potensialet til SMP konfigurasjonen oppnådd. 

Stormaskineksempelet som er presentert på viritualisering er ment å lære forskjel- 

lige topologier som er mulige ved viritualisering av en maskin. Som nevnt, kjører 

programmet en partisjon (inkluderende operativsystemet) som sannsynlig har et 

bilde av resursene tilgjengelig for dem, inkluderende prosessorene, minne og I/O er 

dedikert til en partisjon. Faktisk har ikke programmene noe som helst ide at de 

kjører på en partisjon. Slike programmer er også ikke klar over at topologien til 

deres partisjon og kan derfor ikke gjøre valg basert på slik topologi. Det som behø- 

ves er en måte for programmer å kunne optimalisere konfigurasjonen av topologien 

på hvilke de kjører. 

EP-A-1674987 innbefatter en metode i henhold til innledende delene av krav 1. 

Sammenfatning av oppfinnelsen 

Oppfinnelsen skaffer til veie en fremgangsmåte slik beskrevet i krav 1 og korres- 

ponderende system og dataprogram. 

Svakhetene ved tidligere kjent teknikk er overkommet, og ytterligere fordeler er 

gitt, gjennom frembringelsen av en fremgangsmåte, system og et dataprogram 

som iverksetter et underliggende sett av sovende datamaskinmaskinvareresurser. 

En vertsmaskin omfattende verts-CPU’er kan bli partisjonert i logiske/virtuelle par- 

tisjoner som har gjeste CPU’er. Partisjoneringen er fortrinnsvis avstedkommet ved 

hjelp av fastvare eller ved hjelp av programvare som kan bli anskaffet av et opera- 

tivsystem slik som z/VM fra IBM. Hver gjeste-CPU er en virtuell CPU i det at gjeste- 

programmene ser på gjeste-CPU’ene som faktiske PRU prosessorer, men faktisk 

avbilder den underliggende verten hver gjeste-CPU til verts-CPU-resurser. I en ut- 

førelsesform, er en gjeste-CPU implementert ved bruk av en dek av en verts-CPU 

ved at verten designerer en det av CPU-tiden for gjeste-CPU’en til å benytte seg av 

verts-CPU’en. Det er forestilt at et flertall av gjeste-CPU’er kan være støttet av en 

enkelt verts-CPU, men det motsatte kan også være tilfellet.

5 

10 

15 

20 

25 

30 

I et annet utførelseseksempel, er gjeste-CPU’en emulert av programvare hvor , 

emuleringsrutinene konverterer funksjonene til gjeste-CPU’en (inkluderende in- 

struksjonsdekoding og utførelse) til rutiner som kjører på en verts-CPU. Verts- 

10 

CPU’en er forsynt til å støtte gjeste-CPU’er. 

I et annet utførelseseksempel, kan et første gjestebilde være verten for et andre 

gjestebilde. I hvilket tilfelle den andre gjeste-CPU’en er forsynt av første gjeste- 

CPU’er som selv er forsynt av verts-CPU’er. En ny PERFORM TOPOLOGY FACILITY 

(PTF) instruksjon er forsynt og kjent teknikk STORE SYSTEM INFORMATION (STSI) 

instruksjon er økt for å skaffe til veie en ny SYSIB (SYSIB identifier 15.1.2) som 

skaffer til veie komponentslektskap og logisk pakkingsinformasjon til programva- 

ren. Dette gir programvaren lov å ta i bruk informerte og intelligente valg på hvor- 

dan individuelle elementer, slik som prosesseringsenheter til multiprosessorer, er 

tilegnet til forskjellige applikasjoner og arbeidslaster. Således skaffe til veie infor- 

masjon til et program (OS) for å forbedre ytelsen ved f.eks. å øke den delte ca- 

chens trefforhold. 

En ny PERFORM TOPOLOGY FUNCTION (PTF) instruksjon er brukt av et privilegert 

program (slik som en supervisor, en OS, en kernel o.l.) for å forespørre at CPU- 

konfigurasjonstopologien innen hvilke programmet kjører blir forandret. I en utfø- 

relsesform er topologien til gjeste-CPU’en byttet mellom horisontal og vertikal pola- 

risering. 

Ved å ha kapasiteten til å lære topologiinformasjonen til CPU’en, forstår program- 

met avstanden imellom hvilke som helst to vilkårlige to eller flere CPU’er til en sy- 

metrisk multiprosesseringskonfigurasjon. 

Muligheten anskaffet ved minimering av den samlede avstanden til alle CPU’ene i 

en konfigurasjon, og hvor spesielle applikasjonsprogramgjøremål er sendt ut på 

den individuelle CPU’ene som skaffet til veie overvåkningsprogrammer med mulig- 

heten til å forbedre ytelsen. Den forbedrede ytelsen kan resultere fra en til flere av 

de følgende attributtene som er forbedret av bedre kjennskap til topologi: 

Forkorte avstandene til intern CPU-signalisering. 

Delt lagringsplass, aksessert av multiple CPU’er er mer sannsynlig å befinne seg i 

cacher som er nærmere settet med CPU’er. Derfor er bruk av intern cache-lagring 

begrenset til et mindre undersett av den overliggende maskinen og konfigurasjonen

5 

10 

15 

20 

25 

30 

11 

som tillater raskere cache-til-cache overføring. Nærvær av en lagringslokalisering i 

den nærmeste cachen til en CPU (L1) er signifikant mer sannsynlig å forekomme. 

På grunn av forbedret ytelse, kan antallet av CPU’er som faktisk er i konfigurasjo- 

nen være færre i antall, mens de fortsatt gjør den samme jobben med den samme 

kjøretiden eller mindre. En slik reduksjon av CPU’er minsker antallet kommuni- 

kasjonsstier som hver enkelt CPU må bruke for å kommunisere me de andre 

CPU’ene til konfigurasjonen, dermed videre bidra til totalt sett forbedret ytelse. 

For eksempel, hvis 10 CPU’er behøver å utføre et spesielt program, er den interne 

cache trafikken formidabel, hvor ved hvis det samme programmet kan bli utført på 

en CPU, er det ingen intern cache-trafikk. Dette indikerer at nærværet av ønskede 

lagringsplasser til cachen er garantert å være i cachen til den enkelte CPU, hvis 

dette lageret befinner seg ig et cache i det hele tatt. 

Når lagring og det assosierte cachehierarkiet er lokalt, i motsetning til å være dist- 

ribuert over multiple fysiske rammer (f.eks. bokser osv.) er signalstiene kortere. 

Kjennskapen til topologien indikerer den relative avstanden ved valg av det pas- 

sende undersettet av CPU’er å tilegne til et applikasjonsprogram slik at, selv innen 

et større sett med CPU’er i en SMP-konfigurasjon, optimaliserer undersettet den 

minste avstanden dem imellom. Dette kalles noen ganger en affinitetsgruppe. 

Begrepene relatert til redusering av CPU-antallet og avstanden mellom CPU’er er 

informert av topologiinformasjon som tillater programmet å optimalisere anvisning- 

en av CPU’er til en affinitetsgruppe. 

I en utførelsesform (fig. 20), i et logisk partisjonert vertsmaskin system omfattende 

vertsprosessorer (verts-CPU’er), er topologiinformasjon oppdaget av en eller gjes- 

teprosessorer (gjeste-CPU’er) av en gjestekonfigurasjon og lagret i en tabell. Fort- 

rinnsvis henter en gjesteprosessor til gjestekonfigurasjonene en STORE SYSTEM 

INFORMATION instruksjon for å bli utført. Når den er utført anskaffer STORE SYS- 

TEM INFORMATION instruksjonen, basert på en forespørsel om topologiinformasjon 

av STORE SYSTEM INFORMATION instruksjonen, anskaffer topologiinformasjon til 

datamaskinkonfigurasjonen omfatter stablinginformasjon av prosessorer til konfigu- 

rasjonen. Den anskaffede topologiinformasjonen er lagret i en konfigurasjonstopo- 

logitabell fortrinnsvis i minnet.

5 

10 

15 

20 

25 

12 

I et utførelseseksempel omfatter topologiinformasjonen identifikasjon av vertspro- 

sessorer og stablingsnivåer assosiert med topologien til vertsprosessorene. 

I et annet utførelseseksempel, omfatter topologiinformasjonen informasjon om 

vertsprosessorer til gjestekonfigurasjoner og stablingsnivåer assosiert med topolo- 

gien til vertsprosessorer til gjestekonfigurasjonene. 

I en utførelsesform omfatter STORE SYSTEM INFORMATION instruksjon et opcode 

felt, et grunnregister felt, et signert omplasseringsfelt, hvor instruksjonen for 

topologi oppdaging videre består av et første underforstått generelt register som 

inneholder et funksjonskodefelt og et selektor-1 felt og andre impliserte generell 

registre som inneholder et selektor-2 felt, funksjonskodefelt angir topologi- 

forespørsel om informasjon, et grunnregister felt og et signert omplasseringsfelt 

identifiserer et sted i minnet av en systeminformasjonsblokk (SYSIB) som 

inneholder konfigurasjonstopologitabellen, hvor verdier av selektor-1 feltet og 

selektor-2-feltet, i kombinasjon, bestemmer topologiforespørsel om informasjon 

som skal utføres. 

I en annen utførelsesform, tabellen omfatter en topologilisteprosessoroppføring for 

hver gruppe av stablede prosessorer av prosessorene. 

I enda en utførelsesform omfatter topologilisteprosessoroppføringen ytterligere en 

indikator som indikerer hvor dedikert prosessorene av gruppen med stablede 

prosessorer er ovenfor logiskpartisjongjestkonfigurasjonen. 

I en utførelsesform, inkluderer tabellen videre en topologilistebeholderoppføring av 

hvert stablede nivå for et hierarki av ett eller flere stablende nivåer som har nevnte 

stablende prosessorer. 

I en utførelsesform, er utførelsen av STORE SYSTEM INFORMATION utført av 

emulering på en fremmed prosessor. 

Kort beskrivelse av figurene 

Det temaet som anses som oppfinnelsen er spesielt påpekt og tydelig hevdet i den 

avsluttende delen av spesifikasjonen. Oppfinnelsen imidlertid både med hensyn til 

organisering og fremgangsmåte av praksis, sammen med ytterligere objekter og

5 

10 

15 

20 

25 

30 

fordeler av dette, kan best forstås ved henvisning til følgende beskrivelse tatt i 

13 

forbindelse med de medfølgende figurer der: 

Figur 1 viser et vertsmaskinsystem i henhold til tidligere kjent teknikk; 

Figur 2 viser et emulert vertsmaskinsystem i henhold til tidligere kjent teknikk ; 

Figur 3 viser et instruksjonformat av en kjent teknikk STSI maskin instruksjon; 

Figur 4 viser underforståtte registre over kjent teknikk STSI instruksjon; 

Figur 5 viser en funksjonskodetabell; 

Figur 6 viser en kjent teknikk SYSIB 1.1.1 tabell; 

Figur 7 viser en kjent teknikk SYSIB 1.2.1 tabell; 

Figur 8 viser en kjent teknikk Format-1 SYSIB 1.2.2 tabell; 

Figur 9 viser en kjent teknikk Format-2 SYSIB 1.2.2 tabell; 

Figur 10 viser en SYSIB 15.1.2 tabell i henhold til oppfinnelsen; 

Figur 11 viser en beholdertype TLE; 

Figur 12 viser en CPU type TLE; 

Figur 13 viser et instruksjonsformat av en PTF maskininstruksjon i henhold til 

oppfinnelsen; 

Figur 14 viser et registerformat av PTF instruksjonen; 

Figur 15A-15D viser kjent teknikks elementer av partisjonerte datasystemer; 

Figur 16 viser et eksempel datasystem; 

Figur 17-19 viser beholdere av eksempel datasystemet, og 

Figur 20 viser en flytskjema av en utførelsesform av oppfinnelsen. 

Detaljert beskrivelse 

I en stormaskin, er bygde maskininstruksjoner brukt av programmerere (typisk 

skrive applikasjoner i "C", men også Java®, COBOL, PL/I, PL/X, Fortran og andre 

høynivåspråk), ofte i form av en kompilatorapplikasjon. Disse instruksjonene lagret 

på lagringsmediet kan utføres problemfritt i en z/Arkitektur IBM-Server, eller 

alternativt i maskiner som utfører andre arkitekturer. De kan bli emulert i 

eksisterende og i fremtidige IBM stormaskinservere og på andre maskiner fra IBM 

(f.eks pSeries® Servere og xSeries® Servers). De kan utføres i maskiner som 

kjører Linux på en rekke maskiner som bruker maskinvare produsert av IBM®, 

Intel®, AMD, Sun Microsystems og andre. Ved siden av kjøring på hardware 

under az/Architecture®, kan Linux brukes i tillegg til maskiner som benytter 

emulering av Hercules, UMX, FSI (Fundamental Software, Inc) eller Platform 

Solutions, Inc. (PSI), hvor generelt utførelse er i en emuleringsmodus. I

5 

10 

15 

20 

25 

30 

35 

emuleringsmodus er emulering programvare utført av en reell prosessor for å 

14 

emulere arkitekturen i en emulert prosessor. 

Den reelle prosessoren utfører typisk emuleringsprogramvare bestående enten av 

firmware eller et reelt operativsystem til å utføre emuleringen av den emulerte 

prosessoren. Emuleringsprogramvaren er ansvarlig for henting og gjennomføring av 

instruksjonene til den emulerte prosessorarkitekturen. Den emulerte programvaren 

opprettholder et emulert program mot å holde styr på instruksjonsgrensene. 

Emuleringsprogramvaren kan hente en eller flere emulerte maskin instruksjoner av 

gangen og konvertere en eller flere emulerte maskininstruksjoner til en tilsvarende 

gruppe av reelle maskininstruksjoner for utførelse av den reelle prosessoren. Disse 

konverterte instruksjonene kan være hurtigbufret slik at en raskere konvertering 

kan oppnås. Ikke tåler, må emuleringsprogramvaren opprettholde arkitekturreglene 

for emulert prosessorarkitektur, slik som å sikre at operativsystemer og 

applikasjoner skrevet for den emulerte prosessoren skal fungere korrekt. Videre må 

emuleringsprogramvare gi ressurser identifisert av emulerte prosessor arkitektur, 

inkludert men ikke begrenset til å kontrollere registre, generelle registre (ofte med 

flyttall registre), dynamisk NAT-funksjon, inkludert segment tabeller og side tabeller 

for eksempel avbryte mekanismer, kontekst bryter mekanismer, Time of Day (TOD) 

klokker og bygd for grensesnitt til I / O delsystemer slik at et operativsystem eller 

et program designet for å kjøre på den emulerte prosessoren, kan kjøres på den 

innfødte prosessoren som har emuleringsprogramvare. 

En spesifikk instruksjon som blir emulert blir dekodet, og en subrutine kalt til å ut- 

føre funksjon av individuell veiledning. En emuleringsprogramvarefunksjon som 

emulerer en funksjon til en emulert prosessor er implementert, for eksempel i en 

"C" underrutine eller driver, eller en annen metode for å skaffe til veie en driver for 

den spesifikke maskinvaren som vil være innenfor kunnskapen til en fagmann på 

området etter å ha forstått beskrivelsen av den foretrukne utførelsesformen. For- 

skjellige programvare- og maskinvareemuleringspatenter er inkludert, men ikke 

begrenset til US5551013 for en "multiprosessor for maskinvareemulering" av Beau- 

soleil et al., og US6009261: forhåndsbehandling av lagrede målrutiner for å emule- 

re uforenlige instruksjoner på en mål prosessor "av Scalzi et al; og US5574873: 

Dekoding av gjesteinstrukser om å få direkte tilgang til emuleringsrutiner som 

emulerer gjesteinstruksjoner, av Davidian et al;. US6308255: Symmetrisk mul- 

tiprosesseringsbuss og brikkesett brukt for koprosessorstøtte slik at ikke-innfødt 

kode kan kjøres i et system, av Gorishek et al; og US6463582: dynamisk optimali-

5 

10 

15 

20 

25 

30 

15 

seringsobjektkodeoversetter for arkitekturemulering og dynamisk optimaliserende 

objektkodeoversettelsesmetode for Lethin et al; og US5790825: Metode for å emu- 

lere gjesteinstruksjonene på en vertsmaskin gjennom dynamisk rekompilering av 

vertsinstruksjoner, av Eric Traut, og mange andre, illustrerer en rekke kjente måter 

å oppnå emulering av et instruksjonsformat utformet for en annen maskin for en 

målmaskinen tilgjengelig for fagmenn på området, så vel som kommersielle pro- 

gramvareteknikker som brukes av de som er nevnt ovenfor. 

Med henvisning til FIG. 1, er representative deler av et vertsdatasystem 100 vist. 

Andre arrangementer av komponenter kan også være tatt i bruk i et datasystem 

som er godt kjent innenfor fagfeltet. 

Vertsdatamiljøet er fortrinnsvis basert på z/Arkitektur som tilbys av International 

Business Machines Corporation (IBM®), Armonk, New York. z/Arkitekturen er mer 

fullstendig beskrevet i: z/Architecture Principles of Operation, IBM® Pub. No SA22- 

7832-05, 6thEdition, (april 2007). Datamiljøer basert på z/Arkitektur inkluderer, for 

eksempel eServer og zSeries®, begge fra IBM®. 

Den representative vertsmaskinen 100 består av en eller flere CPU’er 101 i kom- 

munikasjon med hovedlageret (datamaskinminnet 102) samt I/O grensesnittet til 

lagringsenheten 111 og nettverket 101 for å kommunisere med andre datamaski- 

ner eller SAN og lignende. CPU kan ha Dynamic Address Translation (DAT) 103 for 

å transformere program adresser (virtuelle adresser) til virkelige adressen til min- 

ne. En DAT inkluderer vanligvis en Translation Lookaside Buffer (TLB) 107 for hur- 

tigbufring av oversettelser, slik at senere tilgang til blokker med datamaskinens 

minne 102 ikke krever forsinkelse av adresseoversettelse. Vanligvis er en cache 

109 sysselsatt mellom datamaskinminne 102 og prosessoren 101. Cachen 109 kan 

være hierarkisk, ha en stor cache tilgjengelig for mer enn én CPU og mindre, raske- 

re (lavere nivå) cacher mellom den store cachen og hver CPU. I noen implemente- 

ringer er den lavere nivå cachen delt for å gi separate lavt nivå cacher for instruk- 

sjonshenting og datatilgang. I en utførelsesform, er en instruksjon hentet fra min- 

net 102 av en instruksjonshenteenhet 104 via en cache 109. Instruksjonene er de- 

kodet i en instruksjonsdekodeenhet (706) og sendes (med andre instruksjoner i 

noen utførelsesform) til instruksjonsutførelsesenheter 108. Vanligvis er flere in- 

struksjonsutførelsesenheter 108 tatt i bruk, for eksempel en aritmetisk utførelses- 

enhet, en flyttall utførelsesenhet og en gren instruksjonsutførelsesenhet. instruk- 

sjonene er utført av utførelsesenheten, tilgangsoperander fra instruksjonsspesifiser-

5 

10 

15 

20 

25 

30 

te registre eller minne etter behov. Dersom en operand skal bli aksessert (lastet 

16 

eller lagret) fra minnet 102, håndterer en lastlagringsenhet 105 typisk tilgang un- 

der kontroll av at instruksjonen blir utført. 

I en utførelsesform, kan oppfinnelsen utøves av programvare (noen ganger referert 

til som Licensed Internal Code (LIC), fastvare, mikro-kode, milli-kode, pico-kode og 

lignende, noe som ville være i samsvar med den foreliggende oppfinnelsen). Pro- 

gramvare programkode som legemliggjør den foreliggende oppfinnelsen er vanlig- 

vis aksessert av prosessoren også kjent som CPU (Central Processing Unit) 101 til 

datasystem 100 fra langtidslagringsmediet 111, for eksempel en CD-ROM-stasjon, 

tape eller harddisk. Programkoden kan være nedfelt på hvilke som helst av en rek- 

ke kjente medier for bruk med databehandlingssystemer, for eksempel en diskett, 

harddisk eller CD-ROM. Koden kan være distribuert på slike medier, eller kan bli 

distribuert til brukere fra datamaskinens minne 102 eller lagring av et datasystem 

over et nettverk 110 til andre datasystemer for bruk av brukere av andre slike sys- 

temer. 

Alternativt kan den programkoden som innlemmes i minnet 102, og nås ved pro- 

sessoren 101 bruke prosessorbussen. Slik programkode inkluderer et operativsys- 

tem som kontrollerer funksjon og samspillet mellom de ulike datakomponenter og 

ett eller flere applikasjonsprogrammer. Programkoden er vanligvis oppkalt fra tette 

lagringsmedier 111 til høyhastighetsminnet 102 der det er tilgjengelig for behand- 

ling av prosessoren 101. Teknikker og metoder for å utforme programvare pro- 

gramkode i minnet, på fysiske media, og / eller distribuert programvare-kode via 

nettverk er godt kjent og vil ikke bli nærmere diskutert her. Programkode, da opp- 

rettet og lagret på et konkret medium (inkludert men ikke begrenset til elektroniske 

minnemoduler (RAM), flash-minne, kompakte plater (CD), DVD-plater, magnetbånd 

og lignende er ofte referert til som et "dataprogram produkt ". Mediet til datapro- 

gramproduktet er vanligvis lesbart av en prosesseringskrets fortrinnsvis i et data- 

system for utføring av prosesseringskretsen. 

I FIG. 2, er et eksempel på et emulert vertsmaskinsystem 201 anskaffet som emu- 

lerer et vertsmaskinsystem 100 til en vertsarkitektur. I det emulerte vertsmaskin- 

systemet 201, er vertsprosessoren (CPU) 208 en emulert vertsprosessor (eller vir- 

tuell vertsprosessor) og omfatter en emuleringsprosessor 207 som har en annen 

reelle instruksjonssettarkitektur enn det som brukes av prosessoren 101 til vertsda- 

tamaskinen 100. Det emulerte vertsdatasystemet 201 har minne 202 tilgjengelig

5 

10 

15 

20 

25 

30 

17 

for emuleringsprosessoren 207. I utførelseseksempelet er minnet 207 partisjonert i 

en vertsmaskinminnedel 102 og en emuleringsrutinedel 203. Vertsmaskinminnet 

102 er tilgjengelig for programmer til den emulerte vertsmaskinen 201 i henhold til 

vertsmaskinens arkitektur. Emuleringsprosessoren 207 utfører reelle instruksjoner 

av et konstruert instruksjonssett til en arkitektur annen enn den emulerte proses- 

soren 208, de reelle instruksjonene er innhentet fra emuleringsrutineminnet 203, 

og kan få tilgang til en rekke instruksjoner for gjennomføring av et program i 

vertsmaskinminnet 102 ved å ansette en eller flere instruksjon(er) fått i en sekvens 

og tilgangs- / Dekodingsrutine som kan dekode vertsinstruksjon(ene) sin tilgang til 

å avgjøre en reell instruksjonsutførelsesrutine for å emulere funksjonen til vertsin- 

struksjon som aksesseres. 

Andre fasiliteter som er definert for arkitekturen til vertsdatamaskinsystemet 100 

kan bli emulert ved utformede fasilitetsrutiner, herunder slike anlegg som General 

Purpose Registers, kontrollprotokoller, Dynamic Address Translation, og I / O un- 

dersystemsupport og prosessor cache for eksempel. Emuleringsrutinene kan også 

dra nytte av funksjoner tilgjengelig på emuleringsprosessoren 207 (som General 

Registers og dynamisk oversettelse av virtuelle adresser) for å forbedre ytelsen av 

emuleringsrutinene. Spesiell maskinvare og Off Load motorer kan også gis for å 

bistå prosessoren 207 i å emulere funksjonen av vertsmaskinen 100. 

For å gi topologiinformasjon til programmene, er to instruksjoner gitt. Den første er 

en forbedring av en kjent teknikk instruksjon STSI (STORE SYSTEM INFORMATION) 

og den andre er en ny instruksjon PTF (PERFORM TOPOLOGY FUNCTION). 

CPU Topologi Oversikt: 

Med bruk av den nye IBM eSeries stormaskiner, og enda tidligere, har maskin or- 

ganisasjon til knutepunktsstrukturer resultert i en ikke-uniform minnetilgangoppfør- 

sel (NUMA) (noen ganger også kalt "lumpiness"). Formålet med den nye SYSIB 

15.1.2 funksjonsteknikkens STSI (STORE SYSTEM INFORMATION instruksjon og 

den nye PERFORM TOPOLOGY FUNCTION (PTF) instruksjonen er å gi ekstra maskin- 

topologibevissthet til programmet slik at visse optimaliseringer kan utføres (inklu- 

dert forbedret cachetrefforhold) og dermed forbedre den generelle ytelsen. Meng- 

den av verts-CPU ressurer tildelt en multiprosesserings (MP) gjestkonfigurasjon har 

generelt vært spredt jevnt over et antall konfigurerte gjeste-CPU’er. (En gjeste-CPU 

er en logisk CPU gitt til et program, der alle gjeste-CPU’er støttes av programvare- 

/maskinvarepartisjonering på virkelige verts-CPU’er). Slike en jevn spredning inne-

5 

10 

15 

20 

25 

30 

35 

18 

bærer at ingen spesielle gjeste-CPU (eller CPU) er berettiget til noen ekstra verts- 

CPU forsyning enn noen annen vilkårlig fastsatt gjeste-CPU. Denne tilstanden av 

gjestekonfigurasjon, som berører alle CPU’er til konfigurasjonen, kalles "horisontal 

polarisering". Under horisontal polarisering, er tildelingen av en verts-CPU til en 

gjeste-CPU omtrent samme mengde klargjøring for hver gjeste-CPU. Når forsyning- 

en ikke er dedikert, den samme verts-CPU’en som forsyner gjeste-CPU’en også kan 

brukes til bestemmelse av gjeste-CPU’er til en annen gjest, eller andre gjeste- 

CPU’er av samme gjestekonfigurasjon. 

Når den andre gjestekonfigurasjonen er en annen logisk partisjon, må en verts- 

CPU, når aktive i hver partisjon, vanligvis aksessere hovedlageret mer fordi ca- 

chetrefforholdet reduseres ved å måtte dele cacher på tvers av flere flyttingssoner. 

Hvis verts-CPU forsyningen kan endre balansen slik at noen verts-CPU’er er for det 

meste, eller utelukkende, tildelt en gitt gjestekonfigurasjon (og det blir normal at- 

ferd), så blir cachetrefforholdstallet bedre, det samme gjør også ytelsen. En slik 

ujevn spredning innebærer at en eller flere gjeste-CPU’er har rett til ekstra verts- 

CPU forsyning versus andre, vilkårlig fastsatte gjeste-CPU’er som er berettiget til 

mindre verts-CPU forsyning. Denne tilstanden av gjestekonfigurasjon, berører alle 

CPU’er av konfigurasjonen, kalt "vertikal polarisasjon". Arkitekturen som presente- 

res her kategoriserer vertikale polarisasjon inn i tre nivåer av berettigelse for klar- 

gjøring, høy, middels og lav: 

! Høy rett garanterer at ca. 100 % av en verts-CPU blir tildelt en logisk / vir- 

tuell CPU, og tilhørighet blir opprettholdt som en sterk korrespondanse mel- 

lom de to. Med hensyn til klargjøring av en logisk partisjon, når vertikal po- 

larisasjon er i effekt, er berettigelsen av en dedikert CPU definert til å være 

høy. 

! Medium rett garanterer at en uspesifisert mengde verts-CPU ressurser (en 

eller flere verts-CPU’er) blir tilordnet en logisk / virtuell CPU, og eventuell 

gjenværende kapasitet på verts-CPU’en anses å være slakk som kan bli til- 

delt andre steder. Det beste tilfellet for den tilgjengelige slakken ville være å 

tildele det som lokalt slakk hvis det er mulig. Et mindre gunstig resultat opp- 

står hvis den tilgjengelige slakken er tildelt som ekstern slakk. Det er også 

slik at ressursandelen tildelt en logisk CPU med middels ytelsen er en mye 

mykere tilnærming i forhold til 100 % tilnærming av høy rett innstilling. 

! Lav rett garanterer at ca. 0 % av en verts-CPU blir tildelt en logisk / virtuell 

CPU. Men hvis slakk er tilgjengelig, kan en slik logisk / virtuell CPU fortsatt

5 

10 

15 

20 

25 

30 

19 

motta noe CPU ressurser. En modell av stablede beholdere med polarisering 

er ment å gi et nivå av intelligens om maskinens knutepunktsstruktur som 

gjelder for den anmodende konfigurasjon, slik at, generelt sett, kan klynger 

av verts-CPU’er tildeles klynger av gjeste-CPU’er, og dermed bedre så mye 

som mulig delingen av lagring og minimering av forskjellige konfigurasjoner 

som hovedsakelig kolliderer på samme verts-CPU’er. Polarisering og beretti- 

gelsen indikerer forholdet mellom fysiske CPU’er til logisk CPU’er eller logis- 

ke CPU’er til virtuelle CPU’er i en gjestekonfigurasjon, og hvordan kapasite- 

ten tildelt gjestekonfigurasjonen fordeles over CPU’er som utgjør konfigura- 

sjonen. 

Historisk sett har en gjestekonfigurasjon vært horisontalt polarisert. For uansett 

hvor mange gjest CPU’er ble definert i konfigurasjonen, var tildelte verts-CPU res- 

surser spredt jevnt over alle gjeste-CPU’er på en rettferdig, ikke-berettiget måte. 

Det kan sies at vekten av en enkelt logisk CPU i en logisk partisjon når horisontal 

polarisering er i effekten er omtrent lik den samlede vekten til konfigurasjonen delt 

på antall CPU’er. Men med introduksjonen av 2097 og familiemodeller, blir det vik- 

tig å kunne spre verts-CPU ressurser på en annen måte, som kalles vertikal polari- 

sering av en konfigurasjon, og deretter blir graden av klargjøring av gjeste-CPU’er 

med verts-CPU’er angitt som høy, middels eller lav berettigelse. Høy berettigelse er 

i kraft når en logisk / virtuell CPU av en vertikalt polarisert konfigurasjon er full- 

stendig støttet av samme verts-CPU. Medium berettigelse er i kraft når en logisk / 

virtuell CPU av en vertikalt polarisert konfigurasjon er delvis støttet av en verts- 

CPU. Lav ytelsen er i kraft når en logisk / virtuell CPU av en vertikalt polarisert kon- 

figurasjon ikke er garantert noen verts-CPU ressurs, annet enn det som kan bli til- 

gjengelig på grunn av at slakk ressurs bli tilgjengelig. 

CPU Slakk: 

CPU ressurser; det er to typer av slakk CPU ressurser: 

! Lokal slakk blir tilgjengelig når en logisk / virtuell CPU av en konfigurasjon 

ikke bruker alle ressurser som den er berettiget, og slik slakk deretter bru- 

kes i konfigurasjonen av den CPU’en. Lokal slakk er foretrukket overfor eks- 

tern slakk idet bedre trefforhold på cacher er å forvente når slakk brukes in- 

nenfor konfigurasjonen. 

! Ekstern slakk blir tilgjengelig når en logisk / virtuell CPU av en konfigurasjon 

ikke bruker alle ressurser som den er berettiget, og slik slakk deretter bru-

5 

10 

15 

20 

25 

30 

20 

kes utenfor konfigurasjonen av den CPU’en. Ekstern slakk er forventet å stil- 

le lavere trefforhold på cacher, men det er fortsatt bedre enn ikke å kjøre en 

logisk / virtuell CPU i det hele tatt. 

Målet er å maksimere CPU cachens trefforhold. For en logisk partisjon, er mengden 

av fysiske CPU-ressurser bestemt av det samlede systemets vekter som bestemmer 

den CPU-ressursen tildelt hver logisk partisjon. For eksempel i en logisk 3-veis MP 

som er tildelt fysiske CPU-ressurser tilsvarende en enkelt CPU, og er horisontalt 

polarisert, ville hver logisk CPU sendes uavhengig og dermed motta ca. 33 % fysis- 

ke CPU-ressurser. Hvis den samme konfigurasjonen skulle være vertikalt polarisert, 

ville bare en estable logisk CPU kjøres og vil motta ca. 100 % av den tildelte fysiske 

CPU-ressursen (høy berettigelse) mens de resterende to logiske prosessorene nor- 

malt ikke ville bli sendt (lav berettigelse). Slik ressurstildeling er normalt en til- 

nærming. Selv en lav rett CPU kan få noe mengderessurs hvis bare å bidra til at et 

program ikke blir sittende fast på en slik CPU. Ved å gi et middel for et kontrollpro- 

gram for å vise at den forstår polarisering, og å få en indikasjon for hver CPU av 

polariseringen sin, og hvis vertikal polarisasjon, kan graden av berettigelsen, brett 

slik at programmet gjøre mer intelligent bruk av data strukturer som er generelt 

antatt å være lokale for en CPU vs. tilgjengelig for alle CPU’er av en konfigurasjon. 

Dessuten kan et slikt kontrollprogram unngå å dirigere arbeidet til hvilke som helst 

lav rett CPU. Den faktiske fysiske CPU-ressursen tildelt utgjør kanskje ikke et hel- 

tallig antall CPU’er, så det er også mulighet for en eller flere CPU'er i en MP vertikalt 

polarisert konfigurasjon å ha berettigelse, men ikke høy, og dermed resulterer i at 

slike CPU’er har enten middels eller lav vertikal berettigelse. Det er mulig for even- 

tuelle gjenværende lav berettigelse CPU’er å motta noen mengde verts-CPU- 

ressurser. For eksempel kan dette skje når en slik CPU er målrettet, for eksempel 

via en SIGP orden og slakk verts-CPU-ressursen er tilgjengelig. Ellers kan en slik 

logisk / virtuell CPU forbli i en ikke-sendt tilstand, selv om det ellers er i stand til å 

bli sendt. 

Fortrinnsvis i henhold til oppfinnelsen, er et 2-bits polariseringsfelt definert for den 

nye CPU-type "topology-list entry" (TLE) til STORE SYSTEM INFORMATION (STSI) 

instruksjonen. Graden av vertikal polariseringsberettigelse for hver CPU er indikert 

som høy, middels eller lav. Oppdraget er ikke en presis prosentandel, men snarere 

er noe uklar og heuristisk.

5 

10 

15 

20 

25 

30 

21 

I tillegg til vertikal polarisering som et middel til å tilordne vekting til gjeste-CPU’er, 

eksisterer et annet konsept, som er etablering og styring av slakk kapasitet (også 

kalt "white space"). Slakk kapasitet er opprettet under følgende omstendigheter: 

! En høy vertikal CPU bidrar til slakk når gjennomsnittlig utnyttelsesgrad (AU) 

faller under 100 prosent (100-AU). 

! En middels vertikale CPU som har en tilordnet klargjøring av M prosent av 

en verts-CPU bidrar til slakk når gjennomsnittlig utnyttelsesgrad (AU) faller 

under M prosent (M-AU> 0). 

! En lav vertikal CPU bidrar ikke til slakk. 

! En høy vertikal CPU er ikke en forbruker av slakk. 

STORE SYSTEM INFORMATION Instruksjon: 

Et eksempel på en utførelsesform av et format av en STORE SYSTEM INFORMA- 

TION Instruksjon FIG. 3 omfatter et opkode felt 'B27D", e baseregistreringsfelt B2 

og et signert forskyvningsfelt D2. Instruksjonen opkode informerer maskinen som 

utfører instruksjonen at det er underforstått generelle registre '0' og '1' i forbindel- 

se med instruksjonen. En adresse er innhentet fra en andre operand ved å legge 

den signerte forskyvningsfeltverdien til innholdet i det generelle generelle registre- 

re spesifisert av basen feltet. I en legemliggjøring, da basen register feltet spesifi- 

sert av basefeltet. I en utførelsesform, når baseregisterfeltet er '0', er den tegnut- 

videde verdien av forskyvningsfeltet brukt direkte til å angi andre operand. Når 

STORE SYSTEM INFORMATION instruksjon hentes og kjøres, avhengig av en funk- 

sjonskode i det generelle registeret 0, enten en identifisering av nivået av konfigu- 

rasjonen som kjører programmet er plassert i det generelle registeret 0 eller in- 

formasjon om en komponent eller komponenter i en konfigurasjon er lagret i en 

system-informasjon blokk (SYSIB). Når informasjonen om en komponent eller 

komponenter er bedt om, er informasjonen nærmere spesifisert av et videre inn- 

hold av det generelle registeret 0 og av innholdet av det generelle registeret 1. 

SYSIB’en, hvis noen, er utpekt av andre-operand adressen. Maskinen regnes å gi 

ett, to eller tre nivåer av konfigurasjon. Nivåene er: 

1. Den grunnleggende maskinen, som er maskinen som om den opererer i det 

grunnleggende moduset. 

2. En logisk partisjon, som er forutsatt hvis maskinen er i drift i LPAR (logisk 

partisjonert) modus. En logisk partisjon er levert av LPAR hypervisor, som

5 

10 

15 

20 

25 

30 

22 

er en del av maskinen. En grunnleggende maskin foreligger, selv når ma- 

skinen er i drift i LPAR modus. 

3. En virtuell maskin, som leveres av et virtuelt maskinkontrollprogram (VM) 

som er utført enten av en grunnleggende maskin eller i en logisk partisjon. 

En virtuell maskin kan selv utføre et VM kontrollprogram som gir en høyere 

nivå (mer fjernet fra den grunnleggende maskinen) virtuell maskin, som 

også regnes som en nivå-3-konfigurasjon. Begrepene grunnleggende mo- 

dus, LPAR modus, logisk partisjon, hypervisor og virtuell maskin, og even- 

tuelle andre vilkår knyttet spesifikt til disse begrepene, er ikke definert i 

denne publikasjonen, de er definert i maskinens håndbøker. Et program 

som blir utført av en nivå-1-konfigurasjon (grunnleggende maskin) kan be 

om informasjon om den konfigurasjon. Et program blir utført av et nivå-2- 

konfigurasjon (i en logisk partisjon) kan be om informasjon om den logiske 

partisjonen og om den underliggende grunnleggende maskinen. Et program 

blir utført ved en nivå 3-konfigurasjon (en virtuell maskin) kan be om in- 

formasjon om den virtuelle maskinen og om ett eller to underliggende nivå- 

er, en grunnleggende maskin er alltid underliggende, og en logisk partisjon 

kan eller kan ikke være mellom den grunnleggende maskinen og den virtu- 

elle maskinen. Når informasjon om en virtuell maskin er bedt om, er infor- 

masjon om konfigurasjonskjøreprogrammet og om eventuelle underliggen- 

de nivå eller nivåer av virtuell maskiner. I noen av disse tilfellene, er infor- 

masjonen gitt om et nivå bare dersom nivået gjennomfører instruksjonen. 

Funksjonskoden som bestemmer at operasjonen er et usignert binært heltall i bit 

posisjonene 32-35 til det generelle registeret 0 og er som følger: 

Funksjon 

Kode ønsket informasjon: 

0 Nåværende-konfigurasjons-nivånummer 

1 Opplysninger om nivå 1 (grunnleggende maskinen) 

2 Opplysninger om nivå 2 (en logisk partisjon) 

3 Opplysninger om nivå 3 (en virtuell maskin) 

4-14 Ingen; koder er reservert 

15 Gjeldende-konfigurasjonsnivå informasjon

5 

10 

15 

20 

25 

30 

Ugyldig funksjonskode: 

23 

Nivået av konfigurasjonen som kjører programmet kalles nåværende nivå. Konfi- 

gurasjonsnivået angitt av en ikke-null funksjonskode kalles det angitte nivået. Når 

det angitte nivået er nummerert høyere enn nåværende nivå, kalles dermed koden 

for funksjonen ugyldig, tilstandskoden er satt til 3, og ingen andre tiltak (inkludert 

kontroll) er utført. 

Gyldig funksjonskode: 

Når funksjonskoden er lik eller mindre enn tallet til det nåværende nivået, kalles 

det gyldig. I dette tilfellet må bitene 36-55 til det generelle registeret 0 og bitene 

32-47 til det generelle registeret 1 være null eller 15, ellers er et spesifikasjons- 

unntak anerkjent. Bitene 0-31 til det generelle registeret 0 og 1 ignoreres alltid. 

Når funksjonskoden er 0, er et usignert binært heltall som identifiserer det aktuelle 

konfigurasjonsnivået (1 for enkel maskin, 2 for logisk partisjon, eller 3 for virtuell 

maskin) plassert i bitposisjonene 32-35 til det generelle registeret 0, er tilstands- 

koden satt til 0, og ingen ytterligere tiltak er utført. Når funksjonskoden er gyldig 

og ikke-null, inneholder det generelle registeret 0 og 1 flere spesifikasjoner om 

den ønskede informasjonen, som følger: 

! Bit posisjoner 56-63 av generell registrer 0 inneholde en usignert binære 

heltall, kalt selector 1, som angir en komponent eller deler av den angitte 

konfigurasjonen. 

! [0133] Bit posisjoner 48-63 av generell registrere en inneholder en usignert 

binære heltall, kalt selector 2, som angir hvilken type informasjon etter- 

spør. Innholdet av generelle registre 0 og 1 er vist i FIG. 4. 

Når funksjonskoden er gyldig og ikke-null, kan informasjon lagres i en systemin- 

formasjonsblokk (SYSIB) som begynner lokaliseringen til andre-operand. SYSIB’en 

er 4 kB og må begynne på en 4 kB grens, ellers kan et spesifikasjonsunntak bli 

gjenkjent, avhengig av selector 1 og selector 2 og om tilgangsunntak er anerkjent 

på grunn av referanser til SYSIB. 

Selector 1 kan ha verdier som følger: 

Selector 1 ønsket informasjon 

0 Ingen; selector er reservert

5 

10 

15 

20 

25 

30 

1 Informasjon om konfigurasjonsnivået er spesifisert av koden for 

funksjonen 

2 Opplysninger om en eller flere CPU’er i det spesifiserte konfigura- 

sjonsnivået 

24 

3-255 Ingen; selectorer er reservert 

Når selector 1 er 1, kan selector 2 ha verdier som følger: 

Selector 2 når 

Selector 1 er 1 ønsket informasjon 

0 Ingen; selector er reservert 

1 Opplysninger om det angitte konfigurasjonsnivået 

2 Topologi informasjon om det angitte konfigurasjonsni- 

vået 

3-65,535 Ingen; selectorer er reservert 

Når selector 1 er 2, kan selector 2 har verdier som følger: 

Selector 2 når 

Selector 1 er 2 ønsket informasjon 

0 Ingen; selector er reservert 

1 Opplysninger om CPU utfører programmet i det angitte 

konfigurasjonsnivået 

2 Opplysninger om alle CPU’er i det angitte konfigura- 

sjonsnivået 

3-65,535 Ingen; selectorer er reservert 

Kun enkelte kombinasjoner av funksjonskode, selector 1, og selector 2 er gyldige, 

som vist i FIG. 5. 

Når den angitte funksjonskoden, selector-1, og selector-2 kombinasjonen er ugyldig 

(er annet enn som vist i FIG. 5), eller om den er gyldig, men den forespurte infor- 

masjonen er ikke tilgjengelig fordi det angitte nivået ikke gjennomfører eller ikke 

fullt ut gjennomfører instruksjonen eller fordi en nødvendig del av nivået er avin- 

stallert eller ikke initialisert, og forutsatt at et unntak ikke gjenkjennes, er til- 

standskoden satt til 3. Når funksjonskoden er null, er kombinasjonen gyldig, er den

5 

10 

15 

20 

25 

25 

forespurte informasjonen tilgjengelig, og det ikke er noe unntak, er den forespurte 

informasjonen lagret i en system-informasjon blokk (SYSIB) på adressen til den 

andre operanden. 

Noen eller alle av SYSIB kan være hentet før den er lagret. 

En SYSIB kan identifiseres i referanser ved hjelp av "SYSIB fc.s1.s2," hvor "fc", 

"s1" og "s2" er verdiene av en funksjonskoden, selector 1, og selector 2, henholds- 

vis. 

Følgende avsnitt beskriver de definerte SYSIB’en ved hjelp av figurer og tilhørende 

tekst. I tallene, er de forskyvninger som vises til venstre ordverdier (et ord som 

består av 4 byte). "Konfigurasjonen" refererer til konfigurasjonnivået spesifisert av 

funksjonskoden (konfigurasjonsnivået om hvilken informasjon som er forespurt). 

SYSIB 1.1.1 (Basic-Machine Configuration) 

SYSIB 1.1.1 har formatet vist i FIG. 6, der feltene har følgende betydning: 

Reservert: Innholdet av ord 0-7, 13-15 og 29-63 er reservert og lagres som 

nuller. Innholdet i ord 64-1023 er reservert og kan lagres som nuller eller 

forblir uendret. 

Produsent: Ord 8-11 inneholder 16 tegn (0-9 eller store bokstaver AZ) EBC- 

DIC navnet på produsenten av konfigurasjonen. Navnet er venstrejustert 

med etterfølgende blanke tegn hvis nødvendig. 

Type: Ord 12 inneholder de fire tegn (0-9) EBCDIC typenummer til konfigu- 

rasjonen. (Dette kalles maskin-type nummer i definisjonen av STORE CPU 

ID.) 

Model-Capacity Identifier: Ord 16-19 inneholder 16 tegn (0-9 eller store 

bokstaver AZ) EBCDIC modellkapasitetidentifikator til konfigurasjonen. Mo- 

dellkapasitetidentifikator er venstrejustert med etterfølgende blanke tegn 

hvis nødvendig.

5 

10 

15 

20 

25 

30 

26 

Sekvenskodeord 20-23 inneholde 16 tegn (0-9 eller store bokstaver AZ) 

EBCDIC sekvenskode til konfigurasjonen. Sekvenskoden er høyrejustert med 

ledende EBCDIC nuller hvis nødvendig. 

Produksjonsfabrikk: Ord 24 inneholder de fire karakter (0-9 eller store bok- 

staver AZ) EBCDIC kode som identifiserer anlegget for produksjon for konfi- 

gurasjonen. Koden er venstrejustert med etterfølgende blanke tegn hvis 

nødvendig. 

Model: Når Ord 25 ikke er binære nuller, inneholder ord 25-28 16 tegn (0-9 

eller store bokstaver AZ) EBCDIC modell identifikasjon til konfigurasjonen. 

Modellidentifikasjonen er venstrejustert med etterfølgende blanke tegn hvis 

nødvendig. (Dette kalles modellnummer i programmeringsnote 4 på side 10- 

111 av STORE CPU ID.) Når Ord 25 er binære nuller, representerer innholdet 

til ord 16-19 både modell-kapasitet identifikator og modellen. 

Programnotater: 

1. Feltene i SYSIB 1.1.1 er lik de til node beskriveren beskrevet i publikasjonen 

Vanlige I / O-enhet kommandoer og selvbeskrivelse. Imidlertid kan innholdet av 

SYSIB feltene ikke være identisk med innholdet i det tilsvarende nodebeskriverfel- 

tet fordi SYSIB feltene: 

! Tillater flere tegn. 

! Er mer fleksible når det gjelder typen tegn som er tillatt. 

! Gir informasjon som er berettiget annerledes innenfor feltet. 

! Kan ikke bruke samme metode for å bestemme innholdet av felt som sek- 

venskodefeltet. 

2. Modellfeltet i en node beskrivelse tilsvarer innholdet i STSI modellfeltet og 

ikke STSI modell-kapasitet-identifikatorfeltet. 

3. Modellfeltet angir modell av maskinen (dvs. den fysiske modellen), modell- 

kapasitetsidentifikatorfeltet angir en token som kan brukes til å finne en angivelse 

av kapasiteten eller ytelsen i System Library publikasjonen for modellen. 

SYSIB 1.2.1 (Grunnleggende-Maskin CPU) 

SYSIB 1.2.1 har formatet vist i FIG. 7 der feltene har følgende mening:

5 

10 

15 

20 

25 

27 

Reservert: Innholdet av ord 0-19, byte 0 og 1 av ord 25, og ord 26-63 er re- 

servert og lagres som nuller. Innholdet i ord 64-1023 er reservert og kan 

lagres som nuller eller forblir uendret. 

Sekvenskodeord 20-23 inneholde 16 tegn (0-9 eller store bokstaver AZ) 

EBCDIC sekvens kode til konfigurasjonen. Koden er høyrejustert med leden- 

de EBCDIC nuller hvis nødvendig. 

Produksjonanlegg: Ord 24 inneholder de fire karakter (0-9 eller store bok- 

staver AZ) EBCDIC kode som identifiserer anlegget for produksjonen av kon- 

figurasjonen. Koden er venstrejustert med etterfølgende blanke tegn hvis 

nødvendig. 

CPU Adresse: Bytes 2 og 3 til ord 25 inneholde CPU-adressen som denne 

CPU’en er identifisert i en multiprosessorkonfigurasjon. Den CPU-adressen er 

et 16-bit usignert binært heltall. Denne CPU-adressen er den samme som er 

lagret av STORE CPU ADRESSE når programmet utføres av en maskin som 

opererer i grunnleggende modus. 

Programmeringsnotater: 

Flere CPU’er i samme konfigurasjon har samme sekvenskoden, og det er 

nødvendig å bruke annen informasjon, som for eksempel CPU-adressen, for 

å etablere en unik CPU-identitet. Sekvenskoden returneres for en grunnleg- 

gende maskin-CPU og en logisk-partisjons-CPU er identiske og har samme 

verdi som sekvenskoden som returneres for grunnleggende-maskin- 

konfigurasjonen. 

SYSIB 1.2.2 (Grunnleggende-Maskin CPU’er) 

Formatfeltet i byte 0 av ordet 0 bestemmer formatet på SYSIB. Når formatfeltet har 

en verdi på null, har SYSIB 1.2.2 et format-0 layout som vist i FIG. 8. Når format- 

feltet har en verdi på én, har SYSIB 1.2.2 et format-1 layout som vist i FIG. 9. 

Reservert: 

Når formatfeltet inneholder en verdi på null, er innholdet i bytes 1-3 av ord 

0 og ord 1-6 reservert og lagres som nuller. Når formatfeltet inneholder en

5 

10 

15 

20 

25 

30 

Format: 

28 

verdi på én, er innholdet i byte 1 av ord 0 og ord 1-6 reservert og lagres 

som nuller. Når færre enn 64 ord behøves for å inneholde informasjonen for 

alle CPU’ene, er delen av SYSIB’en som etterfølger justeringsfaktorlisten i et 

format-0 SYSIB eller den alternerende-justeringsfaktorlisten i en format-1 

SYSIB opp til ord 63 reservert og lagret som nuller. Innholdet av ord 64 – 

1023 er reservert og kan lagres som nuller kan forbli uforandret. Når 64 el- 

ler flere ord behøves for å inneholde informasjonen for alle CPU’ene, er de- 

len av SYSIB’en som etterfølger justeringsfaktorlisten i et format-0 SYSIB el- 

ler den alternerende-justeringsfaktorlisten i en format-1 SYSIB opp til ord 

1023 reservert og kan bli lagret som nuller eller kan forbli uforandret. 

Byte 0 av ordet 0 inneholder et 8-bit usignert binært heltall som angir formatet på 

SYSIB 1.2.2. 

Alternerende-CPU-kapabilitetsoffset: 

Når formatfeltet har en verdi på én, inneholder bytes 2-3 i ord 0 et 16-bit usignert 

binært heltall som angir forskyvningen i byte av det alternative-CPU- 

kapabilitetsfeltet i SYSIB. 

Sekundær CPU kapabilitet: 

Ord 7 inneholder et 32-bit usignert binært heltall som, når det ikke er null, spesifi- 

serer en sekundær funksjon som kan brukes på visse typer CPU’er i konfigurasjo- 

nen. Det er ingen formell beskrivelse av algoritmen som brukes til å generere dette 

heltallet, bortsett fra at det er den samme som algoritmen som brukes til å genere- 

re CPU evne. Heltallet brukes som en indikasjon på kapasiteten til en CPU i forhold 

til evnen til andre CPU-modeller, og også i forhold til evnen til andre CPU typer in- 

nenfor en modell. Kapabilitetsverdien gjelder for hver av CPU’ene til ett eller flere 

aktuelle CPU typer i konfigurasjonen. Det vil si at alle CPU’er i konfigurasjonen av 

en gjeldende type eller typer har samme evne. Når verdien er null, har alle CPU’er 

av enhver CPU type i konfigurasjonen samme evne, som angitt av CPU evne. Den 

sekundære CPU kapabiliteten kan eller kan ikke være den samme verdi som CPU- 

kapabilitetsverdien. Multiprosesserings-CPU-evne-justeringsfaktorer er også gjel- 

dende for CPU’er hvis funksjoner er spesifisert av den sekundære CPU evnen.

5 

10 

15 

20 

25 

CPU kapabilitet: 

29 

Hvis biter 0-8 av ord 8 er null, inneholder ordet et 32-bit usignert binært heltall (I) i 

området 0

5 

10 

15 

20 

25 

30 

konfigurasjonen, er ikke tilgjengelig for å brukes til å kjøre programmer, og kan 

30 

ikke gjøres tilgjengelig ved utstedelse av instruksjonene for å plassere den i konfi- 

gurerte tilstand. (Det kan være mulig å plassere en reservert CPU i standby eller 

konfigurert tilstand ved hjelp av manuelle handlinger.) 

Multiprosesserings-CPU-kapabilitetsjusteringsfaktorer: 

Fra og med byte 0 og 1 av ord 11, inneholder SYSIB en serie med sammenhengen- 

de to-byte felt, som hver inneholder et 16-bit usignert binært heltall som brukes til 

å danne en justeringsfaktor (fraksjon) for verdien som finnes i CPU -evne feltet. En 

slik brøkdel er utviklet ved hjelp av verdien (V) av de første to-byte felt i henhold til 

én av følgende metoder: 

! Hvis V er i størrelsesorden 0

5 

10 

15 

20 

25 

30 

35 

som en indikasjon på den varslede kapabiliteten til CPU i forhold til den varslede 

31 

kapabiliteten til andre CPU-modeller. Den alternerende kapabilitetsverdi gjelder for 

hver av CPU’ene i konfigurasjonen. Det vil si at alle CPU’er i konfigurasjonen har 

samme alternerende kapabilitet. 

Dermed er brøkdelen representert med hvert to-byte felt så utviklet ved å dele 

innholdet i to byte felt av den indikerte nevneren. Antallet alternative-justerings- 

faktorfelter er én mindre enn antall CPU'er angitt i total-CPU-tallfeltet. Det 

alternative justeringsfaktorfeltet tilsvarer konfigurasjoner med økende antall CPU'er 

i den konfigurerte tilstanden. Det første alternerende justeringsfaktorfeltet tilsvarer 

en konfigurasjon med to CPU'er i den konfigurerte tilstanden. Hvert suksessive 

alternerende justeringsfaktorfelt tilsvarer en konfigurasjon med en rekke CPU'er i 

den konfigurerte tilstanden som er én mer enn for de foregående feltet. 

SYSIB 15.1.2 (konfigurasjonstopologi) 

SYSIB 15.1.2 har formatet vist i FIG. 10. Feltene har den betydning som følger: 

Reservert: Innholdet av bytes 0-1 av ord 0, byte 2 av ordet 2 og ord 3 er 

reservert, og lagres som nuller. Innholdet av ord N-1023 er reservert og kan 

lagres som nuller eller forblir uendret. 

Lengde: Bytes 2-3 av ordet 0 inneholder et 16-bit usignert binært heltall 

som verdi er antall byte av hele SYSIB 15.1.2. Lengden på bare topologi 

listen er bestemt ved å trekke 16 fra lengden verdien i byte 2-3 av ordet 0. 

N i FIG. 10 er bestemt ved å evaluere formelen N = Lengde / 4. 

Mag 1-6: Ord og bytes 0-1 av ord utgjør seks én byte felt der innholdet i 

hver byte angir maksimalt antall beholder-type topologi-oppføringer (TLE) 

eller CPU-type TLE'er på tilsvarende stablings nivå. CPU-type TLE'er er alltid 

funnet bare på Mag1 nivå. I tillegg spesifiserer Mag1 verdien også maksimalt 

antall CPU'er som kan være representert av en beholder-type TLE til Mag2 

nivået. Når verdien av det stablende nivået er større enn én, inneholdende 

stablende nivåer over Mag1 nivå er opptatt av beholder-type TLE'er. En 

dynamisk endring i topologien kan endre antall TLE'er og antall CPU'er på 

Mag1 nivå, men grensene representert ved verdiene av Mag1-6 feltet endres 

ikke innenfor en modell familie av maskiner. 

Topologien er en strukturert liste over oppføringer der en oppføring definerer en 

eller flere prosessorer eller annet er involvert med stablende struktur. Følgende 

illustrerer betydningen av omfanget feltene: 

Når alle CPU'er av maskinen er jevnaldrende og ingen begrensende organisasjon 

eksisterer, annet enn helheten av sentralprosesseringskomplekset selv, er verdien

5 

10 

15 

20 

25 

30 

35 

32 

av stablende nivå 1, Mag1 den estable ikke-null størrelse feltet, og antall lagrede 

CPU-type TLE'er overskrider ikke Mag1 verdien. 

Når alle CPU'er av maskinen er delt inn i likestilte grupper slik at et nivå av kontroll 

eksisterer, er verdien av stablende nivå 2, Mag1 og Mag2 det estable feltet av 

størrelsesorden ikke-null, antall lagrede beholder-type TLE'er overstiger ikke Mag2 

verdien, og antall CPU-type TLE'er lagret innenfor hver beholder overskrider ikke 

Mag1 verdieen. 

Mag3-6 bytes blir likeledes brukt (går i en rett-til-venstre retning) når verdien av 

det stablende nivået faller i området 3-6. 

MStabl: Byte 3 av ordet 2 angir det stablende nivået av topologi som til hvilke 

konfigurasjonen kan forlenges mens du fortsetter å tillate gjesteprogrammet for å 

overleve. Den maksimale MStabl verdien er seks, den minste er én. Hvis MStabl er 

én, er det ingen reelle TLE stabling struktur, er Mag1 det estable ikke-null-feltet i 

Mag1-6-serien, og bare CPU-type TLE'er er representert i topologilisten. MStabl 

verdien angir antall verdier av størrelsesorden ikke-null som begynner med 

størrelsesordensfeltet ved byte av ord 2 (Mag1), fortsetter til venstre når MStabl er 

større enn én, og med de resterende størrelsesordensfeltene lagret som nuller. 

Verdien av MStabl er det maksimale mulig stablende. Ingen dynamisk 

konfigurasjonsendring overskrider denne grensen. 

Topologilisten: Ord av FIG. 10 i området 4 til N-1 spesifiserer en liste av en eller 

flere topologilisteoppføringer (TLE). Hver TLE er et åtte-byte eller seksten-byte felt, 

derfor er N et likt antall ord, og en konsekvens er at en TLE alltid starter på en 

dobbelordgrense. 

Topologilisteoppføringer: Den første TLE i topologi listen begynner på et stablende 

nivå lik MStabl-1. Hele topologilisten representerer konfigurasjonen av utstederen 

av STSI instruksjonen som spesifiserer SYSIB 15.1.2, ingen ytterste beholder TLE 

oppføring blir brukt i det det ville være overflødig med hele listen, og hele 

konfigurasjonen. Der derfor kan det høyeste stablende nivået ha mer enn en enkelt 

likestilt beholder. 

Fig. 11 og 12 illustrerer typene TLE'er, der feltene har følgende definisjoner: 

Stablende nivå (NL): Byte 0 til ord 0 spesifiserer TLE Stablende nivå. 

NL betydning 

0 TLE'en er en CPU-type TLE. 

1-5 TLE'en er en beholder-type TLE.

5 

10 

15 

20 

25 

30 

35 

06-FF Reservert. 

33 

Den første beholder-type TLE'en lagret i en topologiliste eller en 

forelderbeholder har en beholder-ID i området 1-255. Hvis søsken 

beholdere eksistere innenfor samme foreldre, går de i en stigende 

rekkefølge av beholder ID-kort, som kan eller ikke kan være 

sammenhengende, til en maksimal verdi på 255. 

Søsken TLE'er har samme verdi av stablende nivå som tilsvarer enten verdien av 

det stablende nivået minus ett av de umiddelbare foreldre TLE'ene, eller verdien av 

MStabl minus én, fordi den umiddelbare foreldre er topologiliste heller enn en TLE. 

Reservert, 0: For en beholder-type TLE blir bytes 1-3 av ord 0 og bytes 0-2 av ord 

1 reservert og lagret som nuller. For en CPU-type TLE blir bytes 1-3 av ord 0 og 

biter 0-4 av ord 1 reservert og lagret som nuller. 

Beholder ID: 

Byte av ord 1 av en beholder-type TLE angir en 8-bit usignert ikke er null binære 

heltall som verdi identifikatoren av beholderen. Beholderen ID for en TLE er unik 

innenfor samme foreldre beholder. 

Dedikerte (D): 

Bit 5 av ord 1 av en CPU-type TLE, når man, indikerer at en eller flere CPU'er 

representert ved TLE er dedikerte. Når D er null, er en eller flere CPU'er av TLE ikke 

dedikerte. 

Polarisering (PP): 

Bits 6-7 av ord 1 av en CPU-type TLE spesifisere polariseringsverdien og, når 

polariseringen er vertikal, er graden av vertikal polarisasjon også kalt bruksrett 

(høy, middels, lav) av tilsvarende CPU (er) representerte av TLE. Følgende verdier 

brukes: 

PP Betydning: 

0 en eller flere CPU'er representert ved TLE er horisontalt polarisert. 

1 En eller flere CPU'er representert ved TLE er vertikalt polarisert. 

Ytelsen er lav. 

2 en eller flere CPU'er representert ved TLE er vertikalt polarisert. Ytelsen er 

middels.

5 

10 

15 

20 

25 

30 

35 

34 

3 En eller flere CPU'er representert ved TLE er vertikalt polarisert. 

Ytelsen er høy. 

Polariseringen er estable signifikante i en logisk og virtuell 

multiprosesseringskonfigurasjon som bruker delt vertsprosessorer og omhandler 

hvordan ressursen tildelt en konfigurasjon er brukt over CPU'er av konfigurasjonen. 

Når horisontale polarisasjon er i kraft, er hver CPU til en konfigurasjon garantert 

omtrent samme mengde ressurs. Når vertikal polarisasjon er i kraft, er CPU'er av 

en konfigurasjon klassifisert i tre nivåer av ressurs bruksrett: høy, middels og lav. 

Både undersystem reset og vellykket gjennomføring av SIGP set-arkitektur orden 

som spesifiserer ESA/390 modussted en konfigurasjon og alle av dens CPU'er inn i 

horisontale polarisasjon. CPU'er som er umiddelbart rammet er de som er i den 

konfigurerte tilstanden. Når en CPU i standby-tilstand er konfigurert, anskaffer den 

den aktuelle polariseringen til konfigurasjonen og forårsaker en topologiendring av 

denne konfigurasjonen å bli kjent. 

En dedikert CPU er enten horisontalt eller vertikalt polarisert. Når en dedikert CPU 

er vertikalt polarisert, er bruksretten alltid høy. Så når D er 1, er PP enten 00 binær 

eller 11 binær. 

CPU Type: 

Byte 1 av ord 1 av en CPU-type TLE angir et 8-bit usignert binært heltall hvilkes 

verdi er CPU typen til en eller flere CPU'er representert ved TLE. CPU-typeverdien 

angir enten en primær-CPU type eller noen av de mulige sekundære-CPU-typene. 

CPU-Adresse opphav: 

Bytes 2-3 av ord 1 av en CPU-type TLE angir et 16-bit usignert binært heltall 

hvilkets verdi er CPU adressen til den første CPU'en i området av CPU'er 

representert ved CPU maske, og hvis tilstedeværelse er representert av verdien av 

bit posisjon 0 i CPU masken. En CPU-adresse opprinnelse er jevnt delbart med 64. 

Verdien av en CPU-adresse opprinnelse er den samme som den lagret av STORE 

CPU ADRESSE (STAP) instruksjonen når utført på CPU representert ved bit posisjon 

0 i CPU maske.

5 

10 

15 

20 

25 

30 

35 

CPU Maske: 

Ord 2-3 av en CPU-type TLE angir en 64-bits maske der hver bitposisjon 

representerer en CPU. Verdien av CPU-adresse opprinnelsesfeltet pluss en 

35 

bitposisjon i CPU maske lik CPU adressen for tilsvarende CPU. Når et CPU maske bit 

er null, er den tilsvarende CPU ikke er representert ved TLE. CPU er enten ikke i 

konfigurasjonen eller må være representert ved en annen CPU-type TLE. 

Når en CPU maske bit er en, har de tilsvarende CPU den modifiserer- 

attributtverdiene spesifisert av TLE, er i topologien til konfigurasjonen, og er ikke til 

stede i noen andre TLE'er til topologien. 

Derfor, for eksempel hvis CPU-adresseopprinnelsen er en verdi på 64, og bit 

posisjon 15 av CPU masken er en, er CPU 79 i konfigurasjonen og har CPU-type, 

polarisering, berettigelse og dedikasjon som spesifisert av TLE. 

TLE Rekkefølge: 

Modifisererattributtene som gjelder for en CPU-type TLE er CPU-type, polarisering, 

berettigelse og dedikasjon. Polarisering og berettigelse (for vertikal polarisasjon) 

tas som en enkelt atributt, men med fire mulige verdier (horisontal, vertikal-høy, 

vertikal-medium, og vertikal-lav). 

En enkelt CPU TLE er tilstrekkelig til å representere så mange som 64 CPU'er at alle 

har samme modifisererattributtverdier. 

Når mer enn 64 CPU'er eksisterer, eller hele spekteret av CPU-adresser ikke er 

dekket av en enkelt CPU-adresse opprinnelse, og modifisererattributtene er 

konstante, er en egen søsken CPU TLE lagret for hver CPU-adresse opprinnelse, 

som nødvendig, i stigende rekkefølge av CPU-adresse opprinnelse. Hver slik lagret 

TLE har minst én CPU representert. Samlingen av en eller flere slike CPU TLE'er 

kalles et CPU-TLE sett. 

Når flere CPU-typer finnes, er en egen CPU-TLE satt lagret for hver, i stigende 

rekkefølge av CPU type. 

Når flere polarisering-og-berettigelseverdier eksisterer, er en egen CPU-TLE sett 

lagret for hver enkelt, i synkende rekkefølge av polariseringsverdi og grad (vertikal

5 

10 

15 

20 

25 

30 

35 

høy, middels, lav, deretter horisontal). Når til stede, er alle polarisering CPU-TLE 

sett av en gitt CPU type lagret før stable CPU-TLE sett til den stable CPU-typen. 

Når både dedikerte og ikke-dedikert CPU'er eksisterer, er en egen CPU-TLE satt 

36 

lagret for hver, dedikerte vises før ikke-dedikert. Alle TLE'er er sortert forutsatt en 

dybde-første traversering hvor sorteringsrekkefølge fra størst til minst er som 

følger: 

1. CPU type 

a. Laveste CPU-type verdi 

b. Høyeste CPU-type verdi 

2. Polarisering-Berettigelse 

a. Vertikal høy 

b. Vertikal medium 

c. Vertikal lav 

d. Horisontal 

3. Dedikasjon (når gjeldende) 

a. Dedikerte 

b. Ikke dedikert 

Rangeringen av CPU-adresseopprinnelse og modifisererattributter av søsken CPU 

TLE'er innenfor en forelder beholder er gjort i henhold til følgende liste, fortsetter 

som fra høyeste til laveste. 

1. CPU-TLE sett laveste CPU-type verdi, vertikal høy, dedikert 

2. CPU-TLE sett laveste CPU-type verdi, vertikal høy, ikke-dedikert 

3. CPU-TLE sett laveste CPU-type verdi, vertikale medium, ikke-dedikert 

4. CPU-TLE sett laveste CPU-type verdi, vertikal lav, ikke-dedikert 

5. CPU-TLE sett laveste CPU-type verdi, horisontal, dedikert 

6. CPU-TLE sett laveste CPU-type verdi, horisontal, ikke-dedikert 

7. CPU-TLE sett av høyeste CPU-type verdi, vertikal høy, dedikert 

8. CPU-TLE sett av høyeste CPU-type verdi, vertikal høy, ikke-dedikert 

9. CPU-TLE sett av høyeste CPU-type verdi, vertikale medium, ikke-dedikert 

10. CPU-TLE sett av høyeste CPU-type verdi, vertikal lav, ikke-dedikert 

11. CPU-TLE sett av høyeste CPU-type verdi, horisontal, dedikert 

12. CPU-TLE sett av høyeste CPU-type verdi, horisontal, ikke-dedikert

5 

10 

15 

20 

25 

30 

35 

Andre TLE Regler: 

37 

En beholder-type TLE ligger på stablende nivåer i området 1-5. 

En CPU-type TLE ligger på stablende nivå 0. 

Antall søsken beholder-type TLE'er i en topologiliste eller en gitt foreldrene beholder 

ikke overstiger verdien av størrelsesordensbyte (Mag2-6) av det stablende nivået 

tilsvarer søskenene. 

Antall CPU'er representert ved en eller flere CPU-type TLE'er av den overordnede 

beholderen ikke overstiger verdien av Mag1 størrelsesordensbyte. 

Innholdet i en TLE er definert som følger: 

Hvis en TLE er en beholder-type TLE, er innholdet i en liste som følger 

umiddelbart etter den overordnede TLE'en, som består av en eller flere 

barneTLE'er, og hver barneTLE har et stablende nivå av én mindre enn det 

stablende nivået i forelderTLE'en eller topologi-liste enden. 

Hvis en TLE er en CPU-type TLE, er innholdet en eller flere CPU'er, som 

identifisert av andre felt av en CPU TLE. 

Når den første TLE på et stablende nivå er en CPU oppføring, har det maksimale 

stablende nivå 0 blitt nådd. 

Programmeringsnotater: 

En mulig undersøkelsesprosess med en topologiliste er beskrevet. Før en 

undersøkelse av en topologi liste er begynt, er den nåværende-TLE pekeren 

initialisert til å referere til den første eller øverste TLE i topologilisten, er den 

tidligere-TLE pekeren initialisert til null, og deretter er TLE'er undersøkt i en topp- 

til- bunn rekkefølge. 

I det en topologi-liste undersøkelsen skrider frem, er den nåværende-TLE pekeren 

inkrementert ved å øke den nåværende-TLE pekeren med størrelsen på den 

nåværende TLE til hvilke den peker. En beholder-type TLE er inkrementert ved å 

legge åtte til den nåværende-TLE pekeren. En CPU-type TLE er inkrementert ved å 

legge seksten til den nåværende-TLE pekeren. Prosessen med å inkrementere den

5 

10 

15 

20 

25 

30 

35 

38 

nåværende-TLE pekeren inkluderer lagre dens verdi som før-TLE peker rett før den 

økes. TLE undersøkelse er ikke utført hvis topologilisten ikke har noen TLE'er. 

Eksamineringsprosessen er skissert i følgende trinn: 

1. Hvis det gjeldende-TLE stablende nivået er null, og den tidligere-TLE stablende 

nivået er null eller en, representerer nåværende TLE den første CPU-type TLE av en 

gruppe av en eller flere CPU-type TLE'er. Programmet skal utføre nødvendige tiltak 

hensiktsmessige for når en ny gruppe av en eller flere CPU'er er først observert. Gå 

til trinn 5. 

2. Hvis den nåværende-TLE stablende nivået er null, og den tidligere-TLE stablende 

nivået er null, representerer den nåværende TLE'en en senere CPU-type TLE av en 

gruppe CPU-type TLE'er som representerer søsken av CPU'er tidligere observert i 

trinn 1 eller 2. Programmet som skal utføre nødvendige tiltak er hensiktsmessig for 

når størrelsen av en eksisterende søskengruppe av en eller flere CPU'er er økt. Gå 

til trinn 5. 

3. Hvis det nåværende-TLE stablende nivået ikke er null, og det tidligere-TLE 

stablende nivået er null, representerer forutgående TLE en siste eller bare CPU-type 

TLE av en gruppe av en eller flere CPU-type TLE'er. Programmet som skal utføre 

nødvendige tiltak er hensiktsmessig for når en eksisterende gruppe av en eller flere 

CPU'er er fullført. Gå til trinn 5. 

4. Gå til trinn 5. 

Ved eliminasjon, ville dette være tilfelle der det aktuelle-TLE stablende nivået ikke 

er null, og den tidligere-TLE stablende nivået ikke er null. Hvis det nåværende-TLE 

stablende nivået er lavere enn det tidligere-TLE stablende nivå, er retningen av 

topologilisten traversering mot en CPU-type TLE. Hvis det nåværende-TLE stablende 

nivået er større enn det tidligere-TLE stablende nivået, er retningen av topologi- 

liste traverseringen vekk fra en CPU-type TLE. Beholder-type TLE'er blir krysset 

som fører til enten (1) en annen gruppe av CPU-type TLE'er som er en egen gruppe 

i den totale topologien, eller (2) på slutten av topologilisten. I begge tilfeller er 

ingen spesiell behandling nødvendig utover å avansere til stable TLE. 

5. Videre til stable TLE posisjon basert på typen av nåværende TLE. Hvis den 

avanserte nåværende-TLE pekeren tilsvarer slutten av topologi listen:

5 

10 

15 

20 

25 

30 

35 

39 

a. Ingen flere TLE'er av enhver type eksisterer. 

b. Dersom det tidligere-TLE stablende nivået er null, bør programmet 

utføre nødvendige tiltak være hensiktsmessig for når en eksisterende 

gruppe av en eller flere CPU'er er fullført. 

c. Eksamineringen er fullført. 

Ellers går du til trinn 1. 

I et eksempel på en implementering, FIG. 16, består et datasystem av to fysiske 

rammer (Ramme 1 og Ramme 2). Hver ramme inneholder to logikk boards (Board 

1 og Board 2), hovedlageret (Memory) og I / O-adaptere (I / O Kanal 1 og I / O 

Kanal 2) for å kommunisere med eksterne enheter og nettverk. Hvert board 

inneholder to multi-chip moduler (1 Mod, 2 Mod, type 3 og type 4). Hver multi-chip 

modul inneholder to prosessorer (CPU1, CPU2, CPU3, CPU4, CPU5, CPU6 CPU7 og 

CPU8). Hver modul inneholder også en nivå-2 Cache (Cache 1, Cache 2, Cache 3 og 

Cache 4). Hver prosessor (Central Processing Unit eller CPU), inkluderer en nivå-1 

Cache og Oversettelse-Lookaside-Buffer (TLB). TLB bufferets Addresse Translation 

informasjon under dynamisk adresse oversettelse. 

I henhold til oppfinnelsen, FIG. 17, 18 og 19 er komponentene i datasystemet til- 

delt til "beholdere" i henhold til nærhet. Hver modul er tildelt til innerste beholder 

6, 7, 8 og 9 i det CPU’er til hver modul finnes i den innerste nærhet til hverandre. 

Siden modulene er pakket på brett, er modulene i de respektive brettene tildelt til 

stable nivå beholdere 4 og 5. Den stable høyere nærhetsgrupperingen er rammen. 

Brettene til en ramme er lagt til en beholder som representerer rammen (beholdere 

2 og 3). Hele systemet er representert ved beholder 1. 

Det kan sees at to CPU’er på samme modul som CPU1 og CPU2 er i nærmest topo- 

logiskeforhold eller avstand til hverandre og at begge befinner seg i en beholder 

(beholder 6) og ingen beholder grense er krysset når bare de CPU’er er involvert. 

Men hvis CPU1 og CPU8 er involvert, er 4 beholder grenser krysset. CPU1 i behol- 

der 6 er separert av fire beholdere, 5 og 9 fra CPU8. Derfor ved å vite beholder- 

strukturen, kan en bruker få en oversikt over topologien til systemet. 

Selvfølgelig, i et logisk partisjonert system, kan CPU’er deles mellom operativsys- 

temer som tidligere diskutert. Derfor, hvis en logisk partisjon ble tildelt tre logiske 

prosessorer, hver logiske CPU tildelt 20% av hver av de tre virkelige CPU’ene, ville 

partisjonen virke best hvis 3 ekte CPU’er var innerste nærhet til hverandre som 

kommunikasjon mellom CPU og CPU-ressurser (cache og minne for eksempel) ville

5 

10 

15 

20 

25 

40 

virke best. I vårt eksempel, ville CPU1 og CPU2 i en partisjon oppleve mindre tres- 

king av cache linjer i Cache 1 enn hvis de to CPU’ene var CPU1 og CPU8. 

I eksemplet er en partisjon skapt inkludert CPU1, CPU2 og CPU3. Et program som 

opererer i partisjonen utsteder en STSI instruksjon og en SYSIB 15.1.2 (fig. 10) 

tabell returneres til programmet. I dette tilfellet omfatter partisjon en av beholder 6 

og beholder 7 og dermed er det to nivåer av stabler. SYSIB tabellverdiene er: 

MNest feltet er satt til 4, indikerende at topologien inneholder 4 stablingsnivåer, 

som er en absolutt maksimal stabel for modellen, og kan eller kan ikke være fullt 

utnyttet på hvilke som helst vilkårlige topologiliste, avhengig av ressurstildeling til 

gjestekonfigurasjon utstedelse STSI, og hvordan ressurser tildeles til andre gjeste- 

konfigurasjoner av systemet. 

Mag1 feltet er satt til 2 indikerer at 2 CPU’er er tilgjengelig på det mest primitive 

første nivået. 

Mag2 feltet er satt til 2 indikerer at 2 andrenivå (Modul) beholdere er tilgjengelig. 

Mag3 feltet er satt til 2 indikerer 2 tredjenivåer (Boards) er tilgjengelig. 

Mag4 feltet er satt til 2 indikerer 2 fjerdenivåer (Frames) er tilgjengelig. 

I vårt eksempel er de tre prosessorer som finnes i to moduler på samme bord, der- 

for følgende fire TLE oppføringer følger: 

1. NL = 1; CtnrID = 1 (beholder 6) 

2. NL = 0; CPU type = 1 (type CPU); CPU Addr Origin = 0; CPU Mask 0. . . 11 

(CPU1 og CPU2 av adressert CPU) 

3. NL = 1; CtnrID = 2 (beholder 7) 

4. NL = 0; CPU type = 1 (av type CPU-tallet); CPU Addr Origin = 4; CPU Mask 0. . . 

10 (CPU3 av adressert CPU) 

Dermed har programmet en representasjon av den fysiske topologien basert på 

beholderen og CPU TLE’er er returnert. 

Utfør Topologi Funksjon (PTF)

5 

10 

15 

20 

25 

41 

Med henvisning til FIG. 13, består en Utfør Topologi Function (PTF) instruksjon fort- 

rinnsvis av en opcode og et registerfelt R1 som identifiserer en første operand. Inn- 

holdet i det generelle registeret identifisert av R1 spesifiserer en funksjonskode i bit 

posisjoner 56-63, som vist i FIG. 14. 

Den definerte funksjonskodene er som følger: 

FC Betydning 

0 Forespørre om horisontal polarisering. 

1 Forespørre om vertikal polarisering. 

2 Sjekk topologi-endrings status. 

Udefinert funksjonskoder i størrelsesorden 0-255 er reservert for fremtidige utvi- 

delser. 

Ved ferdigstillelse hvis tilstandskoden 2 er satt, er en grunnkode lagret i bit posi- 

sjoner 48-55 til det generelle registeret R1. Bits 16-23 og 28-31 av instruksjonen 

blir oversett. 

Drift av funksjonskode 0: 

Kjøretid fullfører med betingelseskode for enkelte av følgende årsaker og (grunn- 

koder): 

Ingen grunn spesifisert (0). 

Den anmodende konfigurasjonen er allerede horisontalt polarisert (1). 

En topologi endringen er allerede i prosess (2). 

Ellers er en prosess i gang for å plassere alle CPU’er i konfigurasjonen inn i horison- 

tale polarisasjon. 

Gjennomføringen av prosessen er asynkron med hensyn til gjennomføringen av 

instruksjonen og kan ellers ikke være fullført når gjennomføring av instruksjonen er 

ferdig. 

Resulterende Tilstandskode: 

0 Topologi-forandring er initiert 

1 - 

2 forespørsel avvist

5 

10 

15 

20 

25 

3 - 

Drift av Funksjonskode 1: 

42 

Kjøretid fullfører med betingelseskode 2 for noen av følgende årsaker og (grunn- 

koder): 

Ingen grunn spesifisert (0). 

Den anmodende konfigurasjonen er allerede vertikalt polarisert (1). 

En topologi endringen er allerede i prosess (2). 

Ellers er en prosess i gang for å plassere alle CPU’er i konfigurasjonen i vertikal 

polarisering. Gjennomføring av prosessen er asynkron med hensyn til gjennomfø- 

ring av instruksjonen og kan eller kan ikke være fullført når gjennomføring av in- 

struksjonen er ferdig. 


0 Topologiforandring initiert 

1 - 

2 Forespørsel avvist 

3 - 

Drift av funksjonskode 2: topologiforandringsrapportpåventetilstand er sjekket, og 

instruksjonen fullføres med tilstandskodesettet. 


0 Topologiforandringsrapporten ikke i påvente av topologi 

1 endring rapport i påvente 

2 - 

3 - 

En topologi forandring er enhver endring slik at innholdet i en SYSIB 15.1.2 ville 

være forskjellig fra innholdet i SYSIB 15.1.2 før topologi forandringen. 

En topologiforandringsrapportpåventetilstand skapes når en topologi- 

forandringsprosess fullføres. En topologiforandringsrapportpåventetilstand er klarert 

for konfigurasjonen når noen av de følgende er utført:

5 

10 

15 

20 

25 

30 

Gjennomføring av Utfør Topologi Funksjon angir funksjons-kode 2 som fullfører 

med tilstandskode 1. 

43 

STORE SYSTEM INFORMATION for SYSIB 15.1.2 er vellykket utført av hvilken som 

helst CPU i konfigurasjonen. 

Undersystemtilbakestilling utføres. 

Spesielle betingelser: 

Hvis bit posisjonene 0-55 til det generelle registeret R1 er ikke nuller, er et spesifi- 

kasjonsunntak anerkjent. Hvis en udefinert funksjonskode er angitt, er et spesifika- 

sjonsunntak anerkjent. 

Program Unntak: 

Operasjon (Konfigurasjonstopologianlegget er ikke installert) 

Privilegert drift 

Spesifikasjon 

Et eksempel på et stormaskinmiljø: 

I det en high end server arkitekturer øker antallet fysiske prosessorer og proses- 

sorhastigheter fortsette å forbedres, fortsetter prosessor "stabler" som trengs for å 

bygge store maskiner til å være laget av små byggeklosser som er mer nodale i 

natur. For eksempel, mens L2 cache på en z990 eller Z9 maskinen er helt cache- 

sammenhengende, har fullt befolkede modeller faktisk fire (4) separate L2’er som 

er koblet sammen med et stoff for å presentere utseendet av en enkelt L2 cache. 

Straffen for å gå «off node» for å løse en cacheglipp fortsetter å øke. For eksempel 

å løse en L1 glipp i en ekstern L2 er dyrere enn å løse det i den lokal L2. Glipp i en 

CP’s private, vanligvis på chip, L1 cache er dyrt til å begynne med og å måtte gå 

hele veien ut til minne kan virke som en evighet. Økningen i hastighet på minnet 

og forbindelser til det er ikke å holde tritt med økningen i prosessorhastighet. Mens 

man kanskje ønsker å prøve å pakke alt tettere sammen "på chip" eller lignende, 

stride strømforbruk og kjølingsproblemstillinger mot dette. 

Med introduksjonen av z990, ble LPAR oppmerksom på maskintopologi og begynte 

å optimalisere fordelingen av logisk partisjons CP og lagringsressurser til de fysiske 

ressursene. Forbedringer av mulighetene for dynamisk re-optimalisering av logisk 

partisjonsressurstildelingene ble innført med Z9 GA-en primært til støtte for samti- 

dige bok reparasjon.

5 

10 

15 

20 

25 

30 

Den nye støtten diskutert her adresser den virkelige starten på å ha zSeries OS 

programvaren klar over topologien av maskinen, presentert som en logisk parti- 

44 

sjonstopologi, for å deretter gi slektskapsutsending med hensyn til CPU-plassering i 

CEC bokstruktur. 

Du kan tenke på den måten zSeries LPAR forvalter felles logiske partisjoner i dag 

som horisontalt polarisert. Det vil si, prosesseringsvekten for den logiske partisjo- 

nen er likt fordelt mellom alle online logiske CP’er i den logiske partisjonen. Denne 

støtten introduserer en ny, valgfri form for polarisering for å administrere delte lo- 

gisk CP’er av en logisk partisjon som kalles vertikal polarisering. 

Når en logisk partisjon velger å kjøre i vertikal modus, sender programvaren en ny 

instruks for å informere zSeries hypervisor om dette og hypervisoren vil endre 

hvordan den sender den logiske partisjonen. 

Avhengig av konfigurasjonen av den vertikale logisk partisjon, ville logiske proses- 

sorer ha høy, middels eller lav polaritet. Polaritet beskriver mengden av fysisk pro- 

sessordeling som vertikale logiske prosessorer har krav på. Kunder definerer vekter 

for logiske partisjoner som effektivt definerer mengden fysisk prosessorsykluser 

hver logisk partisjon på en maskin er berettiget til. 

Polaritet er målt ved forholdet mellom en logisk partisjons nåværende vekt på an- 

tallet logiske prosessorer konfigurert til den logiske partisjonen. Høy polaritetspro- 

sessorer har nær 100 % CPU andel. Medium polaritetsprosessorer har> 0 til 99 % 

andel og lav polaritet prosessorer har 0 % andel (eller svært nær det). Høy polari- 

tet logisk CP vil bli tildelt en fysisk prosessor til å kjøre på svært lik dedikerte CP, 

men den delte høye polaritets CP kan fortsatt gi opp den fysiske ressurs og la andre 

delte CP’er å bruke sine overflødige sykluser. Nøkkelen her blir da at programvaren 

ser logisk topologi og prøver å utnytte de svært polariserte logiske CP’er for sine 

arbeidskøer. For eksempel konfigurerer en kunde en tre-veis-prosessor med to lo- 

giske partisjoner, hver med to logiske prosessorer og hver med en vekt på 50. Hvis 

den første logiske partisjon definert seg som vertikal, ville det ha 1 høy og 1 mid- 

dels polaritetslogisk CP. 

Merk at når en logisk partisjon velger å kjøre i vertikal modus, går hele den logiske 

partisjonen i vertikal modus. Dette inkluderer alle sine sekundære prosessorer som 

zAAPs (IFAs) og / eller zIIPs. Det er kundens ansvar å definere vekter til alle pro-

5 

10 

15 

20 

25 

30 

sessortypene for disse logiske partisjonene som vil oppnå det ønskede nivået av 

vertikale prosessering for hver type. 

Logisk partisjonstopologistøtte 

45 

! Etablere infrastruktur for en logisk partisjonsnodal topologi. 

! Gjør eventuelle endringer som trengs til LPAR’s nodal oppdragsalgoritmer for 

eksisterende horisontale partisjoner som trengs for å gi en gyldig topologi. 

! Gi instruksjonssimulering for den nye konfigurasjonstopologiinformasjons- 

blokken for den STORE SYSTEM INFORMATION (STSI) instruksen om å gi 

logisk partisjon nodal topologi til den logiske partisjonen. 

! Undersøk endringer i fysiske eller logiske konfigureringer for å avgjøre om 

en topologi endring er nødvendig. Disse kan skje når: 

o En fysisk CP er lagt til eller fjernet fra konfigurasjonen 

o En logisk CP er lagt til eller fjernet fra konfigurasjonen 

o En logisk partisjon er aktivert 

o En logisk partisjon er deaktivert 

o Den logiske partisjonsvekten er endret fra HMC / SE 

o Programvareinitiering av endringer en logisk partisjons vekt. 

o En logisk partisjon er tilbakestilt (bytte til horisontal). 

o En logisk partisjon bytter til ESA/390 modus (bytte til horisontal). 

Algoritmer til miljøet: 

En topologi må tilordnes en logisk partisjon når det først aktiveres og deretter 

eventuelle endringer i nodal topologi tilordnet en logisk partisjon må resultere i at 

den logiske partisjonen blir varslet. Resultatene av nodal topologi må holdes på en 

beleilig ny datastruktur for å tillate enklere spørringer ved den nye STSI behandling 

samt begrense behandlingen best mulig når konfigurasjonen gjør endringer. Denne 

nye strukturen gjør det også mulig for topologiendringsprosessen fullføres i flere 

trinn med den nødvendige serialisering for hvert trinn uten å innføre inkonsekvent 

utsikt over topologien til den logiske partisjonen. 

Topologi tildeling 

Hvordan den logiske topologien er valgt, er ikke viktig for denne utlevering. Det er 

nok å si at en avgjørelse må være laget av hvor mange av hver type logiske pro- 

sessorer som er nødvendige og hvilke noder eller bøker de trenger å bli tildelt. For

5 

10 

15 

20 

25 

30 

46 

en vertikal modus partisjon, betyr dette at antallet av vertikale høye, vertikale me- 

dium, og vertikale lav prosessorer for hver prosessor type. 

Tilordne Polariseringsverdier til logiske CP’er 

Når ovennevnte teller er bestemt, er polariseringsoppdraget laget fra lavest online 

logisk CP-adresse for CP typen til høyeste i rekkefølgen av (1) alle vertikale høye, 

(2) alle vertikale medium, og (3) alle vertikale lave. I hvilken rekkefølge dette er 

gjort er vilkårlig og andre ordre av utvalget er mulig. 

"STORE SYSTEM INFORMATION" Instruksjonsmappinger 

Legg til 3 strukturer for å kartlegge 15.1.2 respons: 

1. Kartlegging for 15.1.2 STSI, Respons Blokk Kartlegging av Topologi 

DCL 1 syibk1512 char (4096) based (*), 

3 * char (2), 

3 syibk1512_length fast (16), lengde 

3 syibk1512_mag6 fast (8), 6thlevel stabel 

3 syibk1512_mag5 fast (8), 5. 



3 syibk1512_mag2 fast (8), 2., noder 

3 syibk1512_mag1 fast (8), 1., CPU’er 

3 * char (1), 

3 syibk1512_mstabl fast (8), stabling nivå 

3 * char (4), 

3 syibk1512_topology_list char (0); topologi liste 

2. Mapping for en Beholder-Type TLE for STSI 15.1.2 

DCL 1 syibk_vcm_beholder char (8) basert (*), 

3 syibknl fast (8), stabling nivå 

3 * char (3), 

3 * char (1), 

3 * char (2), 

3 syibk_beholder_id fast (8); node id

5 

10 

15 

20 

25 

30 

47 

3. Mapping for en CPU-type TLE for STSI 15.1.2 

DCL 1 syibk_vcm_cpu char (16) basert (*), 

TOPBK-partisjonstopologi 

3 syibknl2 fast (8), stabling nivå 

3 * char (3), 

3 syibk_ded_polarization bit (8), VCM byte 

5 * bit (5), 

5 syibk_dedicated bit (1), dedikert bit 

5 syibk_polarization bit (2), polarisasjon biter 

3 syibk_cputype fast (8), CPU typen 

3 syibk_cpuaddrorg fast (16), adresse opprinnelse 

3 syibk_cpumask bit (64); CPU-maskeoppføring 

En oppsummering av en logisk partisjons topologi holdes oppdatert i denne blokken 

av nodaloppdragsrutiner. Dataene i denne blokken er ordnet på en slik måte at 

STSI behandling kan gjøre én gang av hele strukturen for å skape den logiske par- 

tisjonstopologiresponsen på programmet, bevare anordningen og separering av 

CPU oppføringer som kreves av arkitektur. 

Det består av en 3 dimensjonal matrise (node, CP type, polarisasjonsklassifisering) 

med en 64-bits CPU maske per oppføring. 

Et andre arbeidsområde, TOP_WORKING, er inkludert for bruk i oppdateringen av 

topologien. 

DECLARE 

1 TOPBK BASERT BDY (DWORD), 

* / 

* / 

3 TOP_CURRENT, 

5 TOPCPUMASK (1: MAXNODE, / * Hver 1-4 noder 

0: CPUTMAX, / * CP type index 

0:3) / * 4 mulige topologi klassifiseringer når logisk partisjon er vertikal. 

Det er bare 2 klassifiseringer når partisjon er horisontal. 

* /

5 

10 

15 

20 

25 

30 

sering. 

* / 

48 

BIT (64), / * Mask av de logiske prosessorer som faller inn i denne klassifi- 

3 TOP_WORKING CHAR (LENGDE (TOP_CURRENT)); / * Arbeid område for byg- 

ging av ny topologi 

* / 

TO3PO-partisjonstopologioversettelse 

Disse "konstante" oversettelsestabeller brukes av nodal oppdragsrutiner som byg- 

ger topologien (kartlagt av TOPBK) og STSI foredling som leser topologi. 

/****************************/ 

/ * STSI translation arrays: * / 

/****************************/ 

DECLARE 

1 TOPVERT (00:03) BIT (8) / * For vertikale skillevegger, oversetter klassifisering 

index over for å det bygd for D (engasjement) og PP (Polarisasjon) verdier som skal 

returneres for denne gruppen av KP i STSI data 

* / 

STATISK INIT ('00000 'b'1'bPPVH, / * Klassifisering 0: Dedikerte Vertikal høy * / 

‘00000'b'0'bPPVH, / * Klassifisering 1: Delt Vertikal høy * / 

‘00000'b'0'bPPVM, / * Klassifisering 2: Delt Vertikal Medium * / 

'00000 'B'0'bPPVL), / * Klassifisering 3: Delt Vertikal Lav * / 

3 * BIT (5), / * Ubrukt, må byte justering for bit arrays * / 

3 TOPDPP BIT (3), / * Faktisk D, PP verdier til bruk * / 

1 TOPHOR (00:01) BIT (8) / * For horisontal partisjoner, oversetter klassifisering 

index over for å det bygd for D (engasjement) og PP (Polarisasjon) verdier som 

skal returneres for denne gruppen av KP i STSI data. Merk bare de to første klassi- 

fikasjoner kan brukes til en horisontal deling. 

* / 

STATISK INIT ('00000 'b'1'bPPH, / * Klassifisering 0: Dedikerte Horisontal * / 

'00000 'B'0'bPPH), / * Klassifisering 1: Delt Horisontal * / 

3 * BIT (5), / * Ubrukt, må byte justering for bit arrays * / 

3 TOPDPP BIT (3), / * Faktisk D, PP verdier til bruk * / 

/*************************/

5 

10 

15 

20 

25 

30 

/ * NDI oversettelse array * / 

/*************************/ 

49 

1 TOPDPP2CLASS (00:07) Fast / * Brukes av nodal oppdragsrutiner for å opprette 

topologi informasjon. LPDPP brukes som en indeks inn i denne matrisen til å avgjø- 

re hvilken klassifiseringsindeksere logisk CP bør bruke. Denne ene matrisen er bru- 

ket både for horisontale og vertikale partisjoner * / 

STATISK INIT (1, / * Delt, horisontal * / 

3, / * Delt, vertikal lav * / 

2, / * Delt, vertikale medium * / 

1, / * Delt, vertikal høy * / 

0, / * Dedikert, horisontal * / 

0, / * Ikke aktuelt * / 

0, / * Ikke aktuelt * / 

0), / * Dedikerte, vertikal høy * / 

3 * CHAR (4); / * Force å være ikke-enkle element * / 

Logisk Prosessorblokk: 

En 2 bit koding av partisjonspolariseringen kan spores for hver logiske prosessor for 

å gjenspeile sin polarisering. Gruppering av dette med en 1-bit indikasjon på enga- 

sjement gir et komplett polaritetsbilde for en logisk prosessor i 3-bits: 

. . . 

3 LPDPP BIT (3), / * Polarisering, herunder engasjement * / 

4 LPDED BIT (1), / *= 1, er logisk CP dedikert * / 

4 LPPP BIT (2), / * Prosessor Polarisering * / 

. . . 

/ * Kodinger for Prosessor Polarisering * / 

PPH BIT (2) KONSTANT ('00 'B), / * horisontalt polarisert * / 

PPVL BIT (2) KONSTANT ('01 'B), / * vertikalt polarisert-Lav * / 

PPVM BIT (2) KONSTANT ('10 'B), / * vertikalt polarisert-Medium * / 

PPVH BIT (2) KONSTANT ('11 'B), / * vertikalt polarisert-High * / 

Oppdater topologiblokk 

rensk lokal kopi av CPU topologi maske 

DO for hver logisk CP i den logiske målpartisjonen

5 

10 

15 

20 

25 

HVIS den logiske CP er online THEN 

DO 

50 

Polaritets index = Polaritets index hensiktsmessig for den logiske CP polariserings- 

verdi i henhold til de oversatte polariseringsverdier til polaritetsindex matrisen 

Lokal kopi av CPU topologi maske (CPU_address, node, CPtype, Polaritet index) = 

ON END 

END 

IF ny topologi blokk NOT = nåværende topologi blokk for partisjon THEN 

Set topologiendrerapport bit og kopiere den nye topologien til nåværende. 

Instruksjon simulering STSI 15.1.2 

Innen syibk kartlegginger for STSI 15.1.2 respons blokk, har en beholder-type TLE, 

og en CPU-type TLE blitt lagt til. Hovedsaklig, dataene må returneres i beholder (e) 

med oppføringen på det laveste nivået som er en CPU-type TLE. Man kan tenke på 

dette som en rekke matriser basert på hvordan den logiske partisjonsressursen har 

blitt delt eller tildelt. For den foretrukne utførelsesformen, er hver beholder hoved- 

saklig en node med et stablende nivå 1 og inkluderer CPU type TLE (S) som hver 

har et stablings nivå av 0. CPU TLE’er er sortert etter CPU type etterfulgt av klassi- 

fiseringen deres. Vertikal partisjoner har fire klassifiseringer (vertikal dedikert, ver- 

tikal høy delt, vertikale medium delt, og vertikale lav delt) og horisontale partisjo- 

ner har to klassifikasjoner (dedikert og delt). 

Følgende trinn illustrerer et brukt tilfelle for hvordan en STSI 15.1.2 håndteres etter 

at alle åpne sjekker har validert instruksjonsinput. 

For den nåværende inkarnasjonen er en maks på 4 noder og 64 prosessorer antatt. 

Start skanning av topbk, og i en lokal variabel kalt current_node_value oppretthol- 

der verdien av nodeindexen vi nå erpå. Grunnen til at vi trenger dette er fordi hvis 

alle de 64 bit maskene innen en node er null, trenger vi ikke å skape en beholder- 

type TLE for den noden.

5 

10 

15 

20 

25 

51 

Når den første ikke-null oppføringen er funnet innenfor en node, opprettes først en 

beholder-type TLE oppføring for den noden. Innenfor beholder TLE oppføring, er 

stablede verdien 1, etterfulgt av 48 reserverte biter. De siste bitene er Node-ID 

som er den indeksen i topbk av dagens node vi behandler. Når du har opprettet 

beholder-type TLE, opprette en CPU-type TLE for oppføringen med en ikke-null bit 

maske. Innenfor denne oppføringen er stablede nivå 0, etterfulgt av 24 reservert 

biter. De neste 8 bits inkluderer dedikerte bit og polariserings bit. Hvis partisjonen 

er vertikal, fyll inn polariseringen verdi og dedikert bit som følger: 

Klassifisering 0 i topbk er loddrett dedikert, lagre en 11 i PP og 1 i D 

Klassifisering 1 i topbk er loddrett høy delt, lagre en 11 i PP og 0 i D 

Klassifisering 2 i topbk er loddrett medium delt, 10 lagre i PP og 0 i D 

Klassifisering 3 i topbk er loddrett lav delt, lagre en 01 i PP og 0 i D 

For vannrett partisjoner, kun klassifikasjon 0 og 1 er gjeldende. Fyll inn dedikerte 

bit og polariseringsverdi som følger: 

Klassifisering 0 i topbk er horisontal dedikert, lagre en 00 i PP og 1 i D 

Klassifisering 1 i topbk er horisontalt delt, lagre en 00 i PP og 0 i D 

CPU Type, neste verdi som skal fylles i CPU-TLE er bare indeks over andre utvalg 

innen topcpumask i topbk. (0-GP, 2-IFA, 3-IFL, 4-ICF, 1 er for tiden ubrukt). 

1. Den neste verdi er CPU adressens opprinnelse. Denne verdien er eksplisitt 

lagret som 0 som 64 er maks antall CPU’er tilgjengelige i den gjeldende ut- 

førelsesformen. 

2. Den siste verdien i syibk_vcm_cpu er CPU maske, den ikke-null 64 bit 

masken lagret i den stablede matrisen av matriser topcpumask. 

3. For hver ikke-null maske etter den første ikke-null bit maske innen en 

node, lage en egen CPU-type TLE oppføringen og iterere gjennom denne 

prosessen for alle 4 noder. 

Flerprosessors-topologi-endrings-rapport (MTCR) påventer hvis konfigurasjons- 

topologi anlegget er installert og aktivert (ECB.7 er én), og SCA adressen for gjes- 

te-CPU er null, bitposisjonen 0 brukes til å huske topologi-endrings-rapporten-i på-

5 

52 

vente av betingelsen for konfigurasjonen. Tilbakestillingstilstanden av topologi end- 

ring-rapport-i påvente er null. 

Oppfinnelsen beskrevet her er ikke begrenset til topologien til prosessorer. Det kan 

bli verdsatt at den grunnleggende komponenten til oppfinnelsen kunne med fordel 

gjelde andre komponenter enn CPU’er, inkludert men ikke begrenset til co- 

prosessorer, Cacher, TLB’er, interne datastier, datastibuffere, distribuert minne og I 

/ O kommunikasjonsadaptere for eksempel.

5 

10 

15 

20 

25 

30 

P a t e n t k r a v 

53 

1. For et logisk partisjonert vertsmaskinsystem omfattende vertsprosessorer, 

en fremgangsmåte for å oppdage en topologi av en eller flere gjesteprosessorer til 

en gjestekonfigurasjon, metoden er 

k a r a k t e r i s e r t v e d at: 

en gjesteprosessor til en gjestekonfigurasjon henter (2001) en STORE SYSTEM IN- 

FORMATION instruksjon for utførelse, STORE SYSTEM INFORMATION instruksjonen 

definert for en datamaskin arkitektur og STORE SYSTEM INFORMATION instruksjo- 

nen spesifiserer en lokalisering i minnet av en topoligitabell; gjennomføring av 

STORE SYSTEM INFORMATION instruksjonen omfatter: 

basert på en topologiinformasjonforespørsel fra STORE SYSTEM INFORMATION in- 

struksjonen, innhenting (2004) av topologi informasjon av en gjestekonfigurasjon, 

topoligiinformasjonen omfatter informasjon om den logiske grupperingen av pro- 

sessorer til gjestekonfigurasjonen i logiske beholdere i henhold til nærhet; lagring 

(2006) av topologiinformasjonen i konfigurasjonstopologitabellen; hvori konfigura- 

sjonstopologitabellen inkluderer en post av topologilisteprosessorer for et førstenivå 

til en hierarkisk gruppering av prosessorer som har liknende attributter; hvori pos- 

ten av topologilisteprosessorer videre omfatter en indikator som indikerer hvor de- 

dikert prosessorene til gruppen av prosessorer er til den logiske gjestepartisjons- 

konfigurasjonen; og hvori den hierarkiske grupperingen består av en eller flere ni- 

våer, og konfigurasjonstopologitabellen videre inkluderer en topologilistebeholder- 

post av hvert nivå større enn det første nivået, slik at topologilistebeholderposten 

blir brukt når vertsprosessorer til systemet er underindelt i likestilte grupper. 

2. Fremgangsmåte i henhold til krav 1, hvori STORE SYSTEM INFORMATION 

instruksjonen omfatter et opcode felt, et baseregistrerefelt, et signert omrokke- 

ringsfelt, hvori topologioppdagelsesinstruksjonen videre består av e første under- 

forstått generelt register som inneholder et funksjonskodefelt og et selektor-1 felt 

og et andre underforstått generelt register som inneholder et selektor-2 felt, funk- 

sjonskodefeltet angir topologiforespørsel om informasjon, baseregisterfeltet og sig- 

nert omrokkeringsfelt identifiserer et sted i minnet av en systeminformasjonblokk 

(SYSIB) som inneholder konfigurasjonstopologibrett, hvor verdier av selektor-1 

feltet og selektor -2-feltet, i kombinasjon, bestemmer topologiforespørsel om in- 

formasjon som skal utføres.

5 

10 


54 

instruksjonen definert for datamaskinarkitekturen er hentet og utført av en sentral- 

enhet til en alternativ datamaskinarkitektur, 

hvori fremgangsmåten videre består av å tolke STORE SYSTEM INFORMATION in- 

struksjonen til å identifisere en forhåndsbestemt programvarerutine for emulere av 

driften av STORE SYSTEM INFORMATION instruksjonen, og 

hvori gjennomføringen av STORE SYSTEM INFORMATION instruksjonen utgjør kjø- 

ring av forhåndsbestemt programvarerutine for å utføre trinnene i metoden for å 

gjennomføre STORE SYSTEM INFORMATION instruksjonen. 

4. System omfattende midler tilpasset for å utføre alle trinnene til fremgangs- 

måten i henhold til hvilke som helst av de foregående fremgangsmåtekravene 

5. Datamaskinprogram omfattende instruksjoner for å utføre alle trinnene til 

fremgangsmåten i henhold til hvilke som helst av de foregående fremgangsmåte- 

kravene, når nevnte datamaskinprogram er utført på et datamaskinsystem.

5 

10 


54 














5 

10 


54 














5 

10 


54 














5 

10 


54 














5 

10 


54 














5 

10 


54 














5 

10 


54 














5 

10 


54 














5 

10 


54 














5 

10 


54 














5 

10 


54 














5 

10 


54 














5 

10 


54 














5 

10 


54

(12) Oversettelse av europeisk patentskrift - Patentstyret

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?