(12) Oversettelse av europeisk patentskrift

Transkript

1 (12) Oversettelse av europeisk patentskrift (11) NO/EP B1 (19) NO NORGE (1) Int Cl. G06F 9/4 (06.01) G06F 9/ (06.01) G06F 9/0 (06.01) Patentstyret (21) Oversettelse publisert (80) Dato for Den Europeiske Patentmyndighets publisering av det meddelte patentet: (86) Europeisk søknadsnr: (86) Europeisk innleveringsdag (87) Den europeiske søknadens Publiseringsdato () Prioritet US (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 EP / , med inndato (73) Innehaver International Business Machines Corporation, One New Orchard Road, Armonk, NY 04, USA (72) Oppfinner Gainey, Charles W., Intellc/o IBM United Kingdom Limited Intellectual Property Law Hursley Park, Winchester, Hampshire SO21 2JN, Storbritannia Schmidt, Donald W., c/o IBM United Kingdom Limited Intellectual Property Law Hursley Park, Winchester, Hampshire SO21 2JN, Storbritannia Kubala, Jeffrey P., c/o IBM United Kingdom Limited Intellectual Property Law Hursley Park, Winchester, Hampshire SO21 2JN, Storbritannia Farrell, Mark S., c/o IBM United Kingdom Limited Intellectual Property Law Hursley Park, Winchester, Hampshire SO21 2JN, Storbritannia (74) Fullmektig Oslo Patentkontor AS, Postboks 7007 Majorstua, 06 OSLO, Norge (4) Benevnelse Virtuell topologioppdagelse av konfigurasjon av datamaskin (6) Anførte publikasjoner EP-A B1, Perretta R F: "z/architecture overview - part 2", MVS Update, vol January 03 ( ), pages 1-74, XP , Retrieved from the Internet: URL: mvs01.pdf [retrieved on ], US-A B1, EP-A B1

2 1 Teknisk felt Den foreliggende oppfinnelsen gjelder generelt for virtualisering av flerprosessorsystemer. Spesielt relaterer den foreliggende oppfinnelsen seg til at programmer kan oppdage topologi over sine virtuelle miljøer. Bakgrunn for oppfinnelsen. Blant systemets kontrollfunksjoner er evnen til å partisjonere systemet i flere logiske partisjoner (LPARer). En LPAR er en undergruppe av prosessorens maskinvare som er definert til å støtte et operativsystem. En LPAR inneholder ressurser (prosessorer, minne og inn / ut-enheter) og opererer som et uavhengig system. Flere logiske partisjoner kan eksistere innenfor et stormaskin hardwaresystem. I stormaskinsystemer fra IBM inkludert, S/390 (R), I mange år var det en grense på 1 LPARer. Nyere maskiner har (og potensielt mer). Slike maskiner er eksemplifisert ved z / Architecture (R). IBM (R) z / Architecture (R) er beskrevet i z / Architecture Principles of Operation SA publisert april, 07 av IBM. 1 2 Praktiske begrensninger i minnestørrelse, I / O tilgjengelighet, og tilgjengelig prosessorkraft begrenser vanligvis antall LPARer til mindre enn disse maksimumsgrensene. Hardware og firmware som muliggjør partisjonering er kjent som PR / SM (TM) (Prosessor Resource / System Manager). Det er PR / SM funksjoner som brukes til å opprette og kjøre LPARer. Denne forskjellen mellom PR / SM (et innebygd anlegg) og LPARer (resultatet av å bruke PR / SM) blir ofte ignorert og begrepet LPAR brukes samlet for anlegget og dets resultater. Systemansvarlige overdrar deler av minnet til hver LPAR og minnet kan ikke deles mellom LPARer. Administratorene kan gi prosessorer (også kjent som CPer eller CPUer) til bestemte LPARer eller de kan la systemet kontrollerne å sende noen eller alle prosessorer til alle LPARene hjelp av en intern lastbalanserende algoritme. Kanaler (CHPIDs) kan tilordnes bestemte LPARer eller kan deles av flere LPARer, avhengig av innholdet av enhetene på hver kanal. Et system med én prosessor (CP prosessor) kan ha flere LPARer. PR / SM har en intern dispatcher som kan tildele en del av prosessoren til hver LPAR, mye som et operativsystem dispatcher tildeler en del av sin prosessor tid til hver prosess, tråd, eller oppgave.

3 2 1 Partisjoneringskontrollspesifikasjonene befinner seg delvis i IOCDS og er delvis inneholdt i en systemprofil. IOCDSene og profilen befinner seg begge i Support Element (SE) som er rett og slett en bærbar datamaskin inne i systemet. SE kan kobles til en eller flere maskinvareadministrasjonkonsoller (HMCs), som er stasjonære personlige datamaskiner som brukes til å overvåke og kontrollere maskinvare som stormaskin mikroprosessorer En HMC er mer praktisk å bruke enn en SE og kan styre flere forskjellige stormaskiner. Å arbeide fra en HMC (eller fra en SE, i uvanlige omstendigheter), utarbeider en operatør en stormaskin til bruk ved å velge og laste inn en profil og en IOCDS. Disse skaper LPARer og konfigurere kanaler med enhetene tall, LPAR oppgaver, multiple sti informasjoner, og så videre. Dette er kjent som en Power-on Reset (POR). Ved å laste inn en annen profil og IOCDS, kan operatøren fullstendig endre antallet og arten av LPARer og utseendet på I / O-konfigurasjon. Men å gjøre dette er vanligvis forstyrrende for eventuelle operativsystemer og applikasjoner som kjører, og er derfor sjelden gjort uten videre planlegging. Logiske partisjoner (LPARer) er, i praksis, tilsvarende egne stormaskiner. Hver LPAR kjører sitt eget operativsystem. Dette kan være hvilken som helst stormaskin operativsystem, det er ikke nødvendig å kjøre z / OS (R), for eksempel, i hver LPAR. Installasjonsplanleggerne kan velge å dele I / O-enheter på tvers av flere LPARer, men dette er en lokal avgjørelse. 2 Den systemansvarlige kan tildele én eller flere system prosessorer for eksklusiv bruk av en LPAR. Alternativt, kan administratoren tillate alle prosessorer som skal brukes på noen eller alle LPARer. Her gir systemkontrollfunksjonene (ofte kjent som mikrokode eller firmware) en dispatcher å dele prosessorer blant de valgte LPARer. Administratoren kan angi maksimalt antall samtidige prosessorer utførende i hver LPAR. Administratoren kan også angi vektingene for ulike LPARer, for eksempel angi at LPAR1 bør få dobbelt så mye prosessortid som LPAR2. Operativsystemet i hver LPAR er IPLed separat, har sin egen kopi av operativsystemet, har sin egen operatørkonsoll (hvis nødvendig), og så videre. Hvis systemet i en LPAR krasjer, har det ingen effekt på de andre LPARene. I et stormaskinsystem med tre LPARer, for eksempel kan du ha en produksjon z / OS i LPAR1, en testversjon av z / OS i LPAR2, og Linux (R) for S/390 (R) i LPAR3. Hvis dette totale systemet har 8 GB minne, kunne vi ha tildelt 4 GB til LPAR1, 1 GB til LPAR2, 1 GB til LPAR3, og har holdt 2 GB i reserve. Operativsystemkonsollene for de to z / OS LPARene kan være på helt forskjellige steder.

4 3 For de fleste praktiske formål er det ingen forskjell mellom for eksempel tre separate stormaskiner som kjører z / OS (og dele det meste av sin I / O-konfigurasjon) og tre LPARer på samme stormaskin gjør det samme. Med mindre unntak z / OS, kan operatørene, og programmer ikke oppdage forskjellen. De små forskjellene inkluderer muligheten for z/os (hvis tillatt når LPARer ble definert) for å få ytelse og utnyttelsesinformasjon på tvers av hele stormaskin systemet og dynamisk skifte ressurser (prosessorer og kanaler) blant LPARer å forbedre ytelsen. Dagens IBM (R) stormaskiner har et sentralt prosessorkompleks (CPC), som kan inneholde flere ulike typer z / Architecture (R) prosessorer som kan brukes til litt forskjellige formål. Flere av disse formålene er knyttet til kostnadskontroll av programvare, mens andre er mer grunnleggende. Alle prosessorene i CPC begynner som tilsvarende prosessorenheter (PUS) eller motorer som ikke har vært preget for bruk. Hver prosessor er preget av IBM under installasjon eller på et senere tidspunkt. De potensielle karakteristikkene er: 1 Prosessor (CP) Denne prosessortypen er tilgjengelig for normale operativsystemer og programvarer. System Assistanse Prosessor (SAP) 2 Hver moderne stormaskin har minst én SAP; større systemer kan ha flere. Strukturtilpasningsprogrammer kjører internkoden for å gi I / O subsystem. En SAP, for eksempel, oversetter enhetstall og reelle adresser til kanalens sti identifikatorer (CHPIDer), elboks adresser og enhetstall. Det klarer flere baner til styringsenheter og utfører feilgjenoppretting for midlertidige feil. Operativsystemer og applikasjoner kan ikke oppdage strukturtilpasningsprogrammer, og strukturtilpasningsprogrammer bruker ikke noen "normalt" minne. Integrert fasilitet for Linux (R) (IFL) Dette er en normal prosessor med én eller to instruksjoner deaktivert som brukes bare av z / OS (R). Linux bruker ikke disse instruksjonene og kan bli utført av en IFL. Linux kan utføres ved en CP også. Forskjellen er at en IFL ikke telles når du angir modellnummeret av systemet. Dette kan gjøre en betydelig forskjell i programvare kostnader. zaap

5 4 Dette er en prosessor med en rekke funksjoner deaktivert (avbryte behandling, noen instruksjoner) slik at ikke noe fult operativsystem kan kjøres på prosessoren. Imidlertid kan z / OS oppdage tilstedeværelsen av zaap prosessorer og vil bruke dem til å utføre Java (TM)-koden. Den samme Java-kode kan kjøres på en standard CP. Igjen telles zaap motorer ikke når du angir modellnummeret av systemet. Som IFLer, eksisterer de bare for å styre programvare kostnader. ziip 1 System Z9 (TM) Integrert Information Prosessor (ziip) er en spesialisert motor for behandling av kvalifiserte database arbeidsmengder. ziip er utviklet for å hjelpe med lavere programvare kostnader for utvalgte arbeidsbelastninger på stormaskiner, som business intelligence (BI), Enterprise Resource Planning (ERP) og Customer Relationship Management (CRM). ziip forsterker stormaskinrollen som data hub for foretaket ved å hjelpe til å gi direkte tilgang til DB2 (R) mer kostnadseffektiv og redusere behovet for flere kopier av dataene. Integrert Coupling Facility (ICF) Disse prosessorene har bare Licensed Internal Code. De er ikke synlige for vanlige operativsystemer eller applikasjoner. Et koplingsanlegg er i praksis en stor minne kladdeblokk som brukes av flere systemer for å koordinere arbeidet. ICFer må tildeles LPARer som da blir koplingsfasiliteter. Spar En ukarakterisert CPU fungerer som en "reserve". Hvis systemkontrollerne oppdager en sviktende CP eller SAP, kan det erstattes med en reserve CPU. I de fleste tilfeller kan dette gjøres uten systemavbrudd, selv for programmet som kjører på sviktende prosessor. 2 I tillegg til disse karakteristikkene av prosessorer, har noen stormaskiner modeller eller versjoner som er konfigurert til å operere langsommere enn den potensielle hastigheten på sine CPer. Dette er viden kjent som "kne-capping", selv om IBM foretrekker begrepet kapabilitetsinnstillingen, eller noe lignende. Det gjøres ved hjelp av mikrokodeoppdateringen å sette nullsykluser inn i prosessorens instruksjonsstream. Formålet, igjen, er å kontrollere programvarekostnadene ved å ha den minste stormaskin modellen eller versjonen som oppfyller krav til søknaden. IFLer, SAP, zaaper og ziiper og ICFer fungere alltid på full fart på prosessoren fordi disse prosessorene "teller ikke" i beregningene av software priser.

6 1 2 3 Prosessor og CPU kan referere til enten den komplette systemboksen, eller til en av prosessorene (CPU) i systemboksen. Selv om meningen kan være klart fra konteksten av en diskusjon, selv stormaskin fagfolk må avklare hvilken prosessor eller CPU mening de bruker i en diskusjon. IBM bruker begrepet sentral prosessor kompleks (CPC) for å referere til den fysiske samlingen av maskinvare som omfatter hovedlageret, en eller flere sentrale prosessorer, timere, og kanaler. (Noen systemprogrammerere bruke begrepet sentralt elektronisk kompleks (CEC) for å referere til stormaskin "boksen", men den foretrukne begrepet er CPC.) Kort, alle S/390 eller z / Architecture prosessorer innenfor en CPC er prosesseringsenheter (PUS). Når IBM leverer CPC, blir PUS karakterisert som CP (for normalt arbeid), integrert fasilitet for Linux (IFL), Integrert koplingsfasilitet (ICF) for parallelle Sysplex konfigurasjoner, og så videre. Mainframe fagfolk bruker vanligvis systemet til å indikere maskinvareboksen, et komplett maskinvaremiljø (med I / O-enheter), eller et driftsmiljø (med programvare), avhengig av kontekst. De bruker vanligvis prosessoren til å bety en enkelt prosessor (CP) i CPC. z / VM (R) hypervisor (TM) er utviklet for å hjelpe kundene med å utvide virksomhetens verdi av stormaskinteknologien i hele bedriften ved å integrere applikasjoner og data samtidig som det gir eksepsjonelle nivåer av tilgjengelighet, sikkerhet og operasjonell letthet. z / VM virtualiseringsteknologi er utformet for å gi mulighet for kundene å kjøre hundrevis til tusenvis av Linux-servere på en enkelt stormaskin som kjører med andre System z operativsystemer, for eksempel z / OS (R), eller som et storstilt Linux- bare enterprise server løsning. z / VM V.3 kan også bidra til å forbedre produktiviteten ved vertsing av ikke-linux arbeidsbelastninger som z / OS, z / VSE, og z / TPF. z / VM forsyner hver bruker med et individuelt arbeidsmiljø kjent som en virtuell maskin. Den virtuelle maskinen simulerer eksistensen av en dedikert ekte maskin, inkludert prosessor funksjoner, minne, nettverk og input / output (I / O) ressurser. Operativsystemer og applikasjonsprogrammer kan kjøres i virtuelle maskiner som gjester. For eksempel kan du kjøre flere Linux og z / OS bilder på samme z / VM system som også støtter ulike applikasjoner og sluttbrukere. Som et resultat, kan utvikling, testing og produksjonsmiljøer dele en enkelt fysisk maskin. Med henvisning til fig. 1A-1D, partisjonering og virtualisering innebærer et skifte i tenkningen fra fysisk til logisk ved å behandle IT-ressurser som logiske bassenger snarere enn som separate fysiske enheter. Dette innebærer en konsolidering og sammenslåing av IT ressurser, og gir en "enkelt system illusjon" for både homogene og heterogene servere, lagring, distribuerte systemer og nettverk.

7 6 Partisjonering av maskinvare innebærer separat CPUer for separate operativsystemer, som hver kjører sine spesifikke applikasjoner. Software partisjonering sysselsetter en software-basert "hypervisor" for å aktivere enkelte operativsystemer for å kjøre på enkelte eller alle CPUene. 1 2 Hypervisorer tillater flere operativsystemer å kjøre på en vertsmaskin samtidig. Hypervisorteknologi oppsto i IBM VM/370, forgjengeren til z / VM vi har i dag. Logisk partisjonering (LPAR) innebærer å partisjonere firmware (en hardware-basert hypervisor) å isolere operativsystemet fra CPUer. Virtualisering aktiverer eller utnytter fire grunnleggende funksjoner: ressursdeling, ressurs aggregering, emulering av funksjon, og isolasjon. Vi utforsker disse temaene i ytterligere detalj i de følgende avsnittene. z / VM er et operativsystem for IBM System z plattformen som gir et svært fleksibelt test og produksjonsmiljø. Z / VM implementering av IBM virtualiseringsteknologi gir mulighet til å kjøre full funksjons operativsystemer som Linux på System z, z / OS, og andre som "gjester" av z / VM. z / VM støtter 64-bits IBM z / Architecture gjester og 31-bits IBM Enterprise Systems Architecture/390 gjester. z / VM forsyner hver bruker med et individuelt arbeidsmiljø kjent som en virtuell maskin. Den virtuelle maskinen simulerer eksistensen av en dedikert ekte maskin, inkludert prosessor funksjoner, minne, nettverk og input / output (I / O) ressurser. Operativsystemer og applikasjonsprogrammer kan kjøres i virtuelle maskiner som gjester. For eksempel kan du kjøre flere Linux og z / OS (R) bilder på samme z / VM system som også støtter ulike applikasjoner og sluttbrukere. Som et resultat, kan utvikling, testing og produksjonsmiljøer dele en enkelt fysisk maskin. En virtuell maskin bruker ekte maskinvare ressurser, men selv med dedikerte enheter (som en båndstasjon), kan eller kan ikke den virtuelle adressen til båndstasjon være den samme som den virkelige adressen til båndstasjon. Derfor vet en virtuell maskin bare "virtuell maskinvare" som kan eller ikke kan eksistere i den virkelige verden. Et første-nivå z / VM er base operativsystemet som er installert på toppen av ekte maskinvare FIG 16. Et andre-nivå operativsystem er et system som er opprettet ved basen z / VM operativsystem. Derfor kjører z / VM som et base operativsystem på maskinvaren, mens et gjeste operativsystem kjører på virtualiseringsteknologi. I FIG 14, illustrerer et andre nivå gjest z / VM OS lastet inn i en første nivå gjest (gjest-1) partisjon.

8 7 Med andre ord, det er et første-nivå z / VM-operativsystemet som sitter direkte på maskinvaren, men gjestene fra dette første nivå z / VM-systemet er virtualisert. Ved å virtualisere maskinvaren fra gjestene, er vi i stand til å opprette og bruke så mange gjester som nødvendig med en liten mengde hardware. Som tidligere nevnt, operativsystemer som kjører i virtuelle maskiner blir ofte kalt "gjester". Andre uttrykk og setninger du kan støte på er: "Running første nivå" betyr å kjøre direkte på maskinvaren (som er det z / VM gjør). "Running andre nivå", "kjører under VM", eller "kjører på (toppen av) VM" betyr kjører som en gjest. 1 Et eksempel på funksjonaliteten til z / VM er, hvis du har et første-nivå z / VM system og en andre-nivå z / VM-system, kan du fortsette å lage flere operativsystemer på andre nivå system. Denne typen miljø er spesielt nyttig for å teste operativsystemets installasjon før utplassering, eller for testing eller feilsøking av operativsystemer. Virtuelle ressurser kan ha funksjoner eller egenskaper som ikke er tilgjengelige i deres underliggende fysiske ressurser. FIG. 14 illustrerer virtualiseringen av ressurs-emulering. Eksempler er arkitekturemulerings programvare som implementerer en prosessor arkitektur med en annen; iscsi, som implementerer en virtuell SCSI buss på et IPnettverk, og virtuell-tape lagring implementert på fysisk disk lagring. 2 Dessuten er det pakking av sentrale-prosessorer (CPU) i modem teknologi ofte hierarkisk. Flere kjerner kan plasseres på en enkelt brikke. Flere chips kan plasseres i en enkelt modul. Flere moduler kan være pakket på et brett ofte referert til som en bok, og flere bøker kan distribueres over flere rammer. CPU har ofte flere nivåer av cacher, for eksempel hver prosessor kan ha en cache (eller muligens en delt Instruction cache og en data cache) og det kan være flere større cacher mellom hver prosessor og hovedminne grensesnittet. Avhengig av nivå i hierarkiet, er cacher også plassert for å forbedre den generelle ytelsen, og på visse nivåer, kan en cache deles blant mer enn en enkelt CPU. De tekniske beslutninger om slik plassering avtale med plass, strøm / termisk, kablingsavstander, CPU frekvens, systemytelse, og andre aspekter. Denne plasseringen av elementene i CPU skaper en intern struktur som kan være mer eller mindre gunstige for en bestemt logisk partisjon, avhengig av hvor plasseringen av hver CPU på partisjonen ligger. En logisk partisjon gir utseendet til et operativsystem, eierskap av visse ressurser, inkludert prosessorutnyttelsen der i virkeligheten, operativsystemet deler ressurser med andre operativsystemer på andre partisjoner. Normalt er programvaren ikke klar over plasseringen, og i en symmetrisk-

9 8 multiprosessering (SMP) konfigurasjon, observerer et sett av CPUer hvor hver gir samme nivå av ytelse. Problemet er at uvitenhet om den interne emballasje og "avstand" mellom to CPUer kan resultere i at programvaren gjør mindre enn optimale valg på hvordan CPUer kan tildeles arbeid. Derfor er det fulle potensialet på SMP konfigurasjonen ikke nådd. Eksempel på stormaskinvirtualisering presentert er ment å lære ulike topologier mulig i virtualiseringen av en maskin. Som nevnt, de programmene som kjører i en partisjon (inkludert operativsystemer) har sannsynligvis en oppfatning om at de ressursene som er tilgjengelige for dem, inkludert prosessorer, minne og I / O er dedikert til partisjonen. Faktisk trenger programmer ikke ha noen ide om at de kjører i en partisjon. Slike programmer er heller ikke klar over topologien av partisjonen sin og kan derfor ikke ta valg basert på slik topologi. Det som trengs er en måte for programmer å optimalisere for konfigurasjonstopologien som de kjører. EP-A avslører en metode i henhold til den pre-karakterisere delen av krav 1. 1 Peretta RF: «z/architecture overview part 2», MVS Update, Vol.196, 1. Januar 03, sider 1-74 XP , hentet fra internet: URL: [hentet.01.17], viser SYSIB strukturen. Sammenfatning av oppfinnelsen Oppfinnelsen gir en metode som hevdet i krav 1 og tilsvarende system og dataprogram. De teknikkens mangler er overvunnet, og ytterligere fordeler tilbys, gjennom levering av en metode, system, og dataprogram produkt for å aktivere en undergruppe av sovende maskinvare ressurser på et oppgraderbart datasystem har et sett av sovende computer hardware ressurser. 2 En vertsmaskin omfattende verts CPUer kan deles inn i logiske / virtuelle partisjoner som har gjeste CPUer. Partisjoneringen er fortrinnsvis oppnådd ved firmware eller programvare som kan bli gitt av et operativsystem som for eksempel z / VM fra IBM. Hver gjeste CPU er en virtuell CPU i at gjeste programmene viser gjeste CPUer som faktiske prosessorer, men i virkeligheten har den underliggende verten kartlagt hver gjeste CPU til å være verts CPU-ressurser. I en utførelsesform, er en gjeste CPU implementert ved hjelp av en del av en verts CPU av verten utpekt en del av CPU tiden for gjeste CPUen å utnytte verts CPUen. Det er tenkt at et mangfold av gjestecpuer kan bli støttet av en enkelt verts CPU, men det motsatte kan også brukes.

10 9 I en annen utførelsesform, gjeste CPUene etterlignes av programvare der, emuleringsrutiner konverterer funksjoner til gjeste CPUen (inkludert instruksjons dekoding og utførelse) til rutiner som kjører på verts CPUene. Verts CPUene er klargjort for å støtte gjeste CPUene. I en annen utførelsesform, kan et første gjestebilde være vert for et andre gjestebilde. I så fall er den andre gjeste CPUen besørget av første gjeste CPU som selv er utnevnt av verts CPUen. Topologien av konfigurasjoner er en nesting av nivåer av gjeste CPUer og ett eller flere verts CPUer. En ny PERFORM TOPOLOGY FACILITY (PTF) instruksjon gis og teknikkens STORE SYSTEM 1 INFORMATION (STSI) instruksjon er forbedret for å gi en ny SYSIB (SYSIB identifikator 1.1.2) som gir komponent affinitet og logisk emballasje informasjon til programvaren. Dette gjør at programvaren søker informerte og intelligente valg på hvordan de enkelte elementer, for eksempel behandlingsenheter av multi-prosessorer, er tildelt ulike applikasjoner og arbeidsmengder. Dermed gis informasjon til et program (OS) for å forbedre ytelsen ved å øke felles-cache rammede forholdstall for eksempel. En ny PERFORM TOPOLOGY FUNKSJON (PTF) instruksjon brukes av en privilegert program som en veileder, en OS, en kjerne og lignende) for å be om at CPU konfigurasjonstopologien innenfor som programmet kjører endres. I en utførelsesform er gjeste CPU topologien slått mellom horisontal og vertikal polarisering. 2 Ved å ha evnen til å lære CPU topologiinformasjon, forstår programmet "avstand" mellom en vilkårlig to eller flere CPUer av en symmetrisk-multiprosessering konfigurasjon. Muligheten gitt for å minimere den samlede avstanden alle CPUer i en konfigurasjon, og hvordan spesialprogram-programoppgaver sendes på den enkelte CPU gir tilsynsprogrammer med muligheten for å forbedre ytelsen. Resultatfremgangen kan resultere fra en eller flere av følgende egenskaper som er forbedret med bedre topologi kunnskap: Avkortning av Inter-CPU signalveistier. Delt lagring, tilgang til flere CPUer er mer sannsynlig å være i cacher som er nærmere det sett av CPUer. Derfor er inter-cache lagringsplass begrenset til en mindre undergruppe av den samlede maskinen og konfigurasjonen som tillater raskere cache-tilcache overføring. Tilstedeværelse av et lagringssted i det nærmeste bufferet for en CPU (L1) er vesentlig mer sannsynlig å skje. På grunn av forbedret ytelse, kan antall CPUer faktisk i konfigurasjonen være færre i antall, mens de fortsatt får den samme jobben gjort i samme eller mindre kjøretid. En slik reduksjon av CPUer reduserer antall kommunikasjonsveier at hver CPU må brukes for

11 å kommunisere med andre CPUer av konfigurasjonen, og dermed ytterligere bidra til generell ytelsesforbedring. 1 2 For eksempel, hvis prosessorer trenger å utføre et bestemt program, er inter-cache trafikken betydelig mens hvis det samme programmet kan kjøres på en CPU, er det ingen inter-cache trafikk. Dette indikerer at cache tilstedeværelsen av ønskede lagringsplasser er garantert å være i cache av den enkelste CPUen, hvis lagringen er i cache i det hele tatt. Når lagring og tilhørende cachehierarki er lokalt, i motsetning til å bli fordelt over flere fysiske rammer (dvs. bokser, etc.), signaliseringsbaner er kortere. Topologi kunnskap viser den relative avstanden i å velge riktig undergruppe av CPUer tilordnet til et program slik at, selv innenfor et større sett av CPUer i en SMP-konfigurasjon, optimaliserer undergruppen den minimerte avstanden mellom dem. Dette kalles ofte en affinitetsgruppe. De forestillinger om CPU-opptelling reduksjon og avstanden mellom CPUer blir informert av topologi informasjon som gjør at programmet kan optimalisere tildelingen av CPUer til en affinitet gruppe. I en utførelsesform (Fig. ), i et logisk partisjonert vertsmaskinsystem bestående av vertsprosessorer (verts CPU), er topologi informasjonen oppdaget av en eller flere gjesteprosessorer (gjeste CPU) av en gjestekonfigurasjon og lagres i en tabell. Helst, henter en gjesteprosessor av gjestekonfigurasjonen en STORE SYSTEM INFORMASJON instruksjon for utførelse. Under utføringen av STORE SYSTEM INFORMASJON instruksjon, basert på en topologi informasjonsanmodning STORE SYSTEM INFORMASJON instruksjon, henter topologi informasjonen om datamaskinkonfigurasjonen topologiinformasjon bestående av nestingsinformasjonsprosessorer i konfigurasjonen. Innhentede topologiopplysninger lagres i en konfigurasjonstopologitabell fortrinnsvis i minnet. I en utførelsesform, omfatter topologien informasjonen identifisert av vertprosessoren og nestingnivåer forbundet med topologien av vertsprosessorer. I en annen utførelsesform omfatter topologien informasjon om vertsprosessoren gjestekonfigurasjon og nestingnivåer forbundet med topologien av vertsprosessoren gjestekonfigurasjonen. I en utførelsesform omfatter STORE SYSTEM INFORMASJON instruksjon et opcode felt, et baseregisterfelt, et signert fortrengningfelt, hvor topologi oppdagelsesinstruksjonen ytterligere omfatter et første innebærende generelt register inneholdende et

12 11 funksjonskode felt og en velger-1-felt og en andre innebærende generelt register inneholdende et velger-2-felt, funksjonskodefeltet angir topologi forespørsel om informasjon, baseregistrerfeltet og det signerte forskyvningsfeltet identifiserer en plassering i minne om en system informasjonsblokk (SYSIB) som inneholder konfigurasjonstopologitabellen, hvor verdier av velger-1-feltet og velger-2-feltet, i kombinasjon, fastslår topologien forespørsel om informasjon som skal utføres. I en annen utførelsesform, inkluderer tabellen en topologilisteprosessoroppføring for hver gruppe av nestende prosessorer av prosessorene. I enda en utførelsesform, omfatter topologilisteprosessorens oppføring ytterligere en indikator som indikerer hvordan dedikerte prosessorer for gruppen av nestede prosessorer er den logiske partisjons gjestekonfigurasjonen. I en utførelsesform, inkluderer tabellen ytterligere en topologilistebeholderoppføring av hvert nestende nivå for et hierarki av ett eller flere nestende nivåer ha nevnte nestede prosessorer. 1 I en utførelsesform, er gjennomføringen av STORE SYSTEM INFORMASJON utført av emuleringen på en fremmed prosessor. Kort beskrivelse av tegningene Innholdet som regnes som oppfinnelsen er spesielt påpekt og tydelig hevdet i den konkluderende delen av spesifikasjonen. Oppfinnelsen, imidlertid, både med hensyn til organisering og metode for praksis, sammen med ytterligere objekter og fordeler derav, kan best forstås ved henvisning til følgende beskrivelse tatt i forbindelse med tilhørende tegninger der: FIG. 1 skildrer et vertsmaskinsystem fra tidligere kjent teknikk; FIG. 2 skildrer et emulert vertsmaskinsystem fra tidligere kjent teknikk; 2 FIG. 3 skildrer et instruksjonsformat fra tidligere kjent STSI maskin instruksjon; FIG. 4 skildrer implisitt registre fra en tidligere kjent STSI instruksjon; FIG. skildrer en funksjon kode tabell; FIG. 6 skildrer en tidligere kjent SYSIB tabell; FIG. 7 skildrer en tidligere kjent SYSIB tabell; FIG. 8 skildrer en tidligere kjent Format-1 SYSIB tabell;

13 12 FIG. 9 skildrer en tidligere kjent Format-2 SYSIB tabell; FIG. skildrer en SYSIB tabellen i henhold til oppfinnelsen; FIG. 11 skildrer en beholder type TLE; FIG. 12 viser en CPU type TLE; FIG. 13 skildrer et instruksjonsformat av en PTF maskin instruksjon i henhold til oppfinnelsen; FIG. 14 skildrer et registerformat av PTF instruksjonen; FIG. 1A-1D skildrer tidligere kjente elementer av partisjonerte datasystemer; FIG. 16 skildrer et eksempel på et datasystemet; FIG skildrer beholdere for eksempler på datasystemer, og FIG. skildrer et flytskjema av en utførelsesform av oppfinnelsen. DETALJERT BESKRIVELSE 1 2 I en stormaskin, bygd for maskininstruksjoner brukt av programmerere (typisk skriving av applikasjoner i "C", men også Java (R), COBOL, PL / I, PL / X, Fortran og andre høynivå språk), ofte i form av en kompilator applikasjon. Disse instruksjonene som er lagret i lagringsmediet kan utføres direkte i az / Arkitektur IBM Servere, eller alternativt i maskiner som benytter andre arkitekturer. De kan bli emulert i eksisterende og i fremtidige IBM stormaskinservere og på andre maskiner fra IBM (f.eks. pseries (R) Servere og xseries (R) servere). De kan utføres i maskiner som kjører Linux på en rekke maskiner som benytter maskinvare produsert av IBM (R), Intel (R), AMD (TM), Sun Microsystems og andre. Foruten kjøring på i maskiner med az / Architecture (R), kan Linux brukes samt maskiner som benytter emulering av Hercules, UMX, FSI (Fundamental Software, Inc) eller Plattform Solutions, Inc. (PSI), hvor generelt sett utførelsen er i en emuleringsmodus. I emuleringsmodus, er emulering programvare utført av en iboende prosessor for å emulere arkitekturen til en emulert prosessor. De iboende prosessorene utfører vanligvis emuleringsprogramvaren omfattende enten av firmware eller et iboende operativsystem for å utføre emulering av den emulerte prosessoren. Emuleringsprogramvaren er ansvarlig for henting og gjennomføring av instruksjoner fra den emulert prosessorarkitekturen. Emuleringsprogramvaren opprettholder en emulert programteller for å holde styr på instruksjonsgrenser. Emulering programvare kan hente en eller flere emulerte maskininstruksjoner av gangen og konvertere de en eller flere emulerte maskininstruksjonene til en korresponderende

14 gruppe med maskinkodeinstruksjoner for utførelse av den iboende prosessoren. Disse konverterte instruksjonene kan være hurtigbufret slik at en raskere konvertering kan oppnås. Ikke motstående, må emuleringsprogramvaren opprettholde arkitekturreglene i den emulerte prosessorarkitekturen, slik som å sikre operativsystemer og applikasjoner skrevet for at den emulerte prosessoren skal fungere korrekt. Videre må emuleringsprogramvaren gi ressurser identifisert av den emulerte prosessorarkitekturen, inkludert, men ikke begrenset til å kontrollere registre, generelle registre (ofte med flyttall registre), dynamisk adresse oversettelsesfunksjon inkludert segmenttabeller og sidetabeller for eksempel interrupt mekanismer, kontekst bryter mekanismer, tid på dagen (TOD) klokker og bygd for grensesnitt til I / O-undersystemer slik at et operativsystem eller et program utviklet for å kjøre på en emulert prosessor, kan kjøres på den iboende prosessoren som har emuleringsprogramvaren. En spesifikk instruksjon som blir emulert er dekodet, og en subrutine oppkallet for å utføre funksjon av den individuelle instruksjonen. En emuleringsprogramvarefunksjon som emulerer en funksjon av en emulert prosessor er implementert, for eksempel i en "C" subrutine eller driver, eller en annen metode for å gi 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. Ulik programvare og maskinvare-emulerings patenter er inkludert, men ikke begrenset til US 13 for en "Multiprosessor for hardware emulering" av Beausoleil et al, og US : Forhåndsprosessering av lagrede målrutiner for å emulere uforenlige instruksjoner på en målprosessor "av Scalzi et al; og US74873: Dekoding av gjesteinstruksjon for å få direkte tilgang til emuleringsrutiner som emulerer gjesteinstruksjoner, av Davidian et al; US682: Symmetrisk multiprosesseringsbuss og chipsett som brukes for coprosessorstøtte slik at ikke-iboende kode kan kjøre i et system, av Gorishek et al; og US646382: Dynamisk optimalisering av en objektkodeoversetter for arkitekturemulering og dynamisk optimalisering av objektkodeoversettelsesmetode av Lethin et al, og US79082: Metode for å emulere gjesteinstruksjoner på en vertsmaskin gjennom dynamisk rekompilering av vertsinstrukser av Eric Traut, og mange andre, illustrerer en rekke kjente måter å oppnå emulering av et instruksjonsformat bygd for en annen maskin for en målmaskinen tilgjengelig fagfolk på området, samt de kommersielle programvareteknikkene som brukes av de som er referert til ovenfor. Med henvisning til FIG. 1, er det vist representative komponenter i et vertsdatasystem 0. Andre arrangementer av komponenter kan også være i bruk i et datasystem som er godt kjent i tidligere kjent teknikk. Vertsdatamiljøet er fortrinnsvis basert på z / Architecture tilbydd av International Business Machines Corporation (IBM (R)), Armonk, New York. Z / Architecture er mer

15 14 fullstendig beskrevet i: z / Architecture Principles of Operation, IBM (R) Pub. No. SA , 6. utgave, (april 07). Datamiljøer basert på z / Architecture omfatter for eksempel, eserver (TM) og zseries (R), begge fra IBM (R) Den representantive vertsmaskinen 0 omfatter en eller flere CPUer 1 i kommunikasjon med hovedminnet (datamaskinminnet 2) samt I / O-grensesnitt til lagringsenheter 111 og nettverk 1 for å kommunisere med andre datamaskiner eller SANer og lignende. Prosessoren kan ha Dynamic Address Translation (DAT) 3 for å transformere program adresser (virtuelle adresser) inn i virkelige adresseminner. En DAT inneholder vanligvis et Translation Lookaside Buffer (TLB) 7 for mellomlagring av oversettelser, slik at senere tilgang til blokken med datamaskinens minne 2 ikke krever utsettelse pga. adresseoversettelse. Vanligvis er en cache 9 brukt mellom datamaskinens minne 2 og prosessoren 1. Bufferen 9 kan være hierarkisk og ha en stor cache tilgjengelig til mer enn én CPU og mindre, raskere (lavere nivå) cacher mellom den store bufferen og hver CPU. I noen implementeringer er lavere nivå cachene er delt for å gi separate lavere nivå cacher for henting av instruksjoner og data aksesser. I en utførelsesform, er en instruksjon hentet fra hukommelsen 2 ved en instruksjonshenteenhet 4 via en cache 9. Instruksjonene er dekodet i en instruksjondekodeenhet (706) og sendes (med andre instruksjoner i enkelte utførelsesformer) til instruksjonsutførende enheter 8. Vanligvis er flere utførende enheter 8 brukt, for eksempel en aritmetisk utførelsesenhet, en flyttallsutførelsesenhet og en avgrenings instruksjonutførelsesenhet. Instruksjonen er utført av utførelsesenheten, tilgangsoperander fra instruksjonsspesifiserteregistre eller minne etter behov. Dersom en operand skal bli gitt tilgang til (lastet eller lagret) fra minnet 2, en lastlagringsenhet håndterer typisk tilgang under kontroll av instruksjonene som blir utført. I en utførelsesform, kan oppfinnelsen utøves av programvare (noen ganger referert til godkjent intern maskinkode (LIC), firmware, mikro-kode, Milli-kode, pico-kode og lignende, noe som ville være forenlig med foreliggende oppfinnelse). Software programkode som fremhever den foreliggende oppfinnelsen er vanligvis aksessert med prosessoren også kjent som en CPU (Central Processing Unit) 1 av datasystem 0 fra langtidslagrings media 111, for eksempel en CD-ROM-stasjonen, tape eller harddisk. Programkoden som innlemmes på noen av en rekke kjente medier for bruk med et databehandlingssystem, for eksempel en diskett, harddisk eller CD-ROM. Koden kan distribueres på slike medier, eller kan bli distribuert til brukere fra datamaskinminnet 2 eller lagring av et datasystem over et nettverk 1 til andre datasystemer for bruk av brukerne av slike andre systemer.

16 Alternativt kan programkoden som innlemmes i minnet 2, og nås ved prosessoren 1 ved hjelp av prosessorbussen. Slik programkode inkluderer et operativsystem som styrer funksjonen og samspillet mellom ulike PC komponenter og ett eller flere programmer. Programkode er normalt oppsøkt fra tette lagringsmedia 111 til høyhastighetsminne 2 der det er tilgjengelig for behandling av prosessoren 1. De teknikker og metoder for legemliggjøring av program kode i minnet, på fysiske media, og / eller distribuere programvare kode via nettverk er godt kjent og vil ikke bli nærmere diskutert her. Programkode, da opprettet og lagret på et konkret medium (inkludert men ikke begrenset til elektroniske minnemoduler (RAM), flashminne, kompakte disker (CD), DVDer, magnetbånd og lignende blir ofte referert til som et «dataprogramprodukt». Dataprogramproduktmediet er vanligvis lest av en behandlingskrets fortrinnsvis i et datasystem for gjennomføring av behandlingskretsen. I FIG. 2, er det gitt et eksempel på et emulert vertsdatasystem 1 forutsatt at emulerer et vertsmaskinsystem 0 av en vertsarkitektur. I emulert vertsmaskinen system 1, er vertsprosessor (CPU) 8 en emulert vertsprosessor (eller en virtuell vertsprosessor) og omfatter en emuleringsprosessor 7 som har en annen iboende instruksjonssettarkitektur enn den brukt av prosessoren 1 på vertsdatamaskinen 0. Det emulerte vertsdatasystemet 1 har minne 2 tilgjengelig for emuleringsprosessoren 7. I eksemplet på utførelsesformen blir minnet 7 partisjonert i et vertsmaskinminneporsjon 2 og en emuleringsrutinedel 3. Vertsmaskinminnet 2 er tilgjengelig for programmer fra den emuleringsvertsmaskinen 1 i henhold til vertsmaskinarkitekturen. Emuleringsprosessoren 7 utfører iboende instrukser til et arkitektert instruksjonssett til en arkitektur annen enn den emulerte prosessoren 8, de iboende instruksjoner er innhentet fra emuleringsrutineminnet 3, og kan få tilgang til en rekke instruksjoner for gjennomføring av et program i vertsmaskinminnet 2 ved å ansette en eller flere instruksjon (er) oppnådd i en sekvens og Access / Decode rutine som kan dekode vertsinstruksjon (e) gitt tilgang til for å bestemme en iboende instruksjon utførelsesrutine for å emulere funksjonen til vertsinstruksjonstilgangen. Andre innretninger som er definert for vertsmaskinsystemets 0 arkitektur kan bli emulert ved arkitekterte fasilitets rutiner, inkludert slike fasiliteter som General Purpose Registers, kontrollstrukturregistre, Dynamic Address Translation, og I / O Subsystem support og prosessor cache for eksempel. Emuleringsrutiner kan også dra nytte av funksjonen tilgjengelig i emuleringsprosessor 7 (som General Registre og dynamisk oversettelse av virtuelle adresser) for å forbedre ytelsen til emuleringsrutiner. Spesiell maskinvare og uten last, motorer kan også gis for å bistå prosessoren 7 i å emulere funksjonen til vertsmaskinen 0.

17 16 For å gi topologiinformasjonen til programmer, er to instrukser gitt. Den første er en forbedring av en teknikkinstruksjonen STSI (STORE SYSTEM informasjon) og den andre er en ny instruksjon PTF (PERFORM TOPOLOGY funksjon). CPU Topologi Oversikt: Med ankomsten av de nye IBM Eseries stormaskiner, og selv tidligere, har maskin organisasjon til nodal strukturer resulterte i en ikke-uniform minne aksess (NUMA) atferd (noen ganger også kalt "lumpiness"). Formålet med den nye SYSIB funksjonteknikkens STSI (STORE SYSTEM INFORMASJON) instruksjon og den nye PERFORM TOPOLOGY FUNKSJON (PTF) instruksjonen er å gi ekstra maskintopologibevissthet til programmet slik at visse optimaliseringer kan utføres (inkludert bedre cache-hit forholdstall) og dermed forbedre den generelle ytelsen. Mengden verts-cpu ressurs som er tildelt en multiprosesserings (MP) gjestekonfigurasjon generelt har blitt spredt jevnt over antall konfigurert gjestecpuer. (En gjestecpu er en logisk CPU gitt til et program, blir alle gjestecpuer støttet av software / hardwarepartisjonering på faktiske vertscpuer). En slik jevn fordeling innebærer at ingen spesiell gjestecpu (eller CPUer) har rett til noen ekstra verts-cpu forsyning enn noen andre vilkårlige fastsatte gjestecpuer. Denne tilstanden av gjestekonfigurasjonen, og rammer alle CPUer til konfigurasjonen, kalles "horisontal polarisering". Under horisontal polarisasjon, er tildeling av en rekke CPUer til en gjestecpu omtrent samme mengde klargjøring for hver gjestecpu. Når tilrettelegging ikke er dedikert, samme vertscpuer som forsyner gjestecpuer også kan brukes til bestemmelse av gjestecpuer til en annen gjest, eller andre gjestecpuer av samme gjestekonfigurasjon. Når den andre gjestekonfigurasjonen er en annen logisk partisjon, en vertscpu, når aktiv i hver partisjon, må typisk ha tilgang til hovedlageret mer fordi cache-treff forholdtallet er redusert med å måtte dele de cachene over multiple relokaliseringssoner. Hvis verts- CPU forsyning kan endre balansen slik at enkelte vertscpuer er stort sett, eller til og med utelukkende, er tildelt en gitt gjestekonfigurasjon (og som blir normal atferd), deretter blir cache-treff forholdstallet bedre, slik som også ytelsen. En slik ujevn spredning innebærer at ett eller flere gjestecpuer har rett til ekstra verts-cpu forsyning versus andre, vilkårlig bestemte gjestecpuer som er berettiget til mindre verts-cpu klargjøring. Denne tilstanden av gjestekonfigurasjonen, og rammer alle CPUer av konfigurasjonen, kalles "vertikal polarisering". Arkitekturen som presenteres her kategoriserer vertikal polarisasjon inn i tre nivåer av berettigelsen for klargjøring, høye, middels, og lav: Høy rett garanterer tilnærmet 0% av en vertscpu blir tildelt en logisk / virtuell CPU, og dens affinitet opprettholdes som en sterk korrespondanse mellom de to. Med hensyn til

18 17 forsyningen av en logisk partisjon, da vertikal polarisasjon er i kraft, er rett for en dedikert CPU definert til å være høy. 1 2 Medium rett garanterer en uspesifisert mengde vertscpu ressurser (en eller flere vertscpuer) blir tildelt en logisk / virtuell CPU, og eventuell gjenværende kapabilitet på vertscpuen anses å være slakk som kan bli tildelt andre steder. I beste fall for de tilgjengelige slakk ville være å tildele den som lokal slakk hvis det er mulig. Et mindre gunstig resultat oppstår hvis det er tilgjengelig slakk blir tilordnet som ekstern slakk. Det er også slik at ressursandelen tildelt en logisk CPU middels rett er en mye mykere tilnærming i forhold til 0% tilnærming av en høy-rett innstilling. Lav rett garanterer ca. 0% av en rekke CPU som blir tildelt en logisk / virtuell CPU, men hvis slakk er tilgjengelig, kan en slik logisk / virtuell CPU fortsatt motta noen CPUressurser. En modell av nestede beholdere med polarisering er ment å gi en grad av intelligens om maskinens nodale struktur idet det gjelder for den anmodende konfigurasjon, slik at generelt sett, kan klynger av vertscpuer tildeles klynger av gjestecpuer, og dermed bedre så mye som mulig deling av lagring og minimering av ulike konfigurasjoner som i hovedsak kolliderer på samme vertscpuer. Polarisering og rett indikerer forholdet mellom fysiske CPUer til logiske CPUer eller logisk CPUer til virtuelle prosessorer i en gjestekonfigurasjon, og hvordan kapabiliteten tildelt gjestekonfigurasjonen fordeles over CPUer som utgjør konfigurasjonen. Historisk sett har en gjestekonfigurasjon vært horisontalt polarisert. For uansett hvor mange gjestecpuer ble definert til konfigurasjonen ble verts-cpu ressurs tildelt spredt jevnt over alle gjestecpuer i en rettferdig, ikke-berettiget måte. Det kan sies at vekten av en enkelt logisk CPU i en logisk partisjon når horisontal polarisering i realiteten er tilnærmet lik den totale konfigurasjonsvekten delt på antall CPUer. Men med innføringen av 97 og familiemodeller, blir det viktig å kunne spre verts-cpuressurser på en annen måte, som kalles vertikal polarisering av en konfigurasjon, og deretter graden av overføring av gjestecpuer med vertscpuer blir angitt som høy, middels eller lav berettigelse. Høy rett er i kraft når en logisk / virtuell CPU av en vertikalt polarisert konfigurasjon er helt støttet av den samme vertscpuen. Medium rett er i kraft når en logisk / virtuell CPU til en vertikalpolarisert konfigurasjon er delvis støttet av en rekke CPUer. Lav rett er i kraft når en logisk / virtuell CPU av en vertikalt polarisert konfigurasjon ikke er garantert noen verts-cpu ressurer, annet enn det som kan bli tilgjengelig på grunn av slakkressursen som blir tilgjengelig. CPU Slakk: 3 CPU ressurser, er det to typer slakkcpu ressurser:

19 18 Lokal slakk blir tilgjengelig når en logisk / virtuell CPU av en konfigurasjon ikke bruker alle de ressurser som det er berettiget, og slik slakk brukes deretter i konfigurasjonen av CPU. Lokal slakk er å foretrekke fremfor ekstern slakk som bedre trefforholdstall på cacher forventes når slakk brukes innenfor konfigurasjonen Ekstern slakk blir tilgjengelig når en logisk / virtuell CPU til en konfigurasjon ikke bruker alle de ressurser den er berettiget, og slik slakk brukes deretter utenfor konfigurasjonen av CPU. Ekstern slakk forventes å utvise lavere rammede forholdstall på cacher, men det er fortsatt bedre enn ikke å kjøre en logisk / virtuell CPU i det hele tatt. Målet er å maksimere CPU cache trefforholdstall. For en logisk partisjon, er mengden av fysiske-cpu ressurser bestemt av de samlede systemvektene som bestemmer CPU ressurser tildelt hver logiske partisjon. For eksempel, i en logisk 3-veis MP som er tildelt fysiske-cpu ressurer tilsvarende en enkelt CPU, og er horisontalt polarisert, ville hver logiske CPU sendes uavhengig og dermed motta ca 33% fysisk-cpu ressurs. Hvis den samme konfigurasjonen skulle være vertikalt polarisert, ville bare én logisk CPU kjøres og vil motta ca 0% av den tildelte fysiske-cpu ressuren (høy berettigelse) mens de resterende to logiske prosessorer normalt ikke ville bli sendt (lav berettigelse). Slik ressurstildeling er normalt en tilnærming. Selv en lav berettigelse CPU kan få en viss mengde ressurser hvis bare for å bidra til at et program ikke blir sittende fast på en slik CPU. Ved å gi et middel for et kontrollprogram for å indikere at den forstår polarisering, og å få en indikasjon for hver CPU av polariseringen sin, og hvis vertikal polarisering, graden av retten, kan kontrollprogrammet gjør mer intelligent bruk av datastrukturer som er generelt antatt å være lokale for en CPU vs tilgjengelig for alle CPUer til en konfigurasjon. Dessuten kan et slikt kontroll program unngå å dirigere arbeidet med lav berettigelse CPU. Den faktiske fysiske CPU ressursen tildelt utgjør kanskje ikke et integrert antall CPUer, så det er også muligheten for en eller flere CPU'er i en MP vertikalt polarisert konfigurasjon ha rett, men ikke i stor grad, og dermed resultere i at en slik CPU enten har middels eller lav vertikal berettigelse. Det er mulig for eventuelle gjenværende lav- berettigelse CPUer å motta enkelte mengder av 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 ressurs er tilgjengelig. Ellers kan en slik logisk / virtuell CPU forbli i en usendt tilstand, selv om det ellers er i stand til å bli sendt. Foretrukket ifølge oppfinnelsen, er et to-bits polariseringsfelt definert for den nye CPUtype "topologi-liste entry" (TLE) av STORE SYSTEM informasjon (STSI) instruksjon. Graden av vertikal-polariseringsrett for hver CPU er indikert som høy, middels eller lav. Oppgaven er ikke en presis prosentandel, men snarere er noe uklar og heuristisk.

20 19 I tillegg til vertikal polarisering som et middel for å tilordne vekting av gjestecpuer, et annet konsept eksisterer, som er etablering og styring av slakkapabilitet (også kalt "white space"). Slakkapabiliteten er opprettet under følgende forhold: En høy vertikal CPU bidrar til slak når gjennomsnittlig utnyttelsesgrad (AU) faller under 0 prosent (0-AU). En middels vertikal CPU som har en tildelt levering av M prosent av en rekke CPUer 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 INFORMASJON instruksjon: 1 2 Et eksempel på utførelsesformen av et format av en STORE SYSTEM INFORMASJON instruksjon FIG. 3 omfatter et opcode-felt 'B27D', et baseregistrefelt B2 og et signert forskyvningsfelt D2. Instruksjons-opcode informerer maskinen som utfører instruksjonen at det er underforstått generelle registrerer '0 'and'1' knyttet til instruksjonen. En adresse oppnås av en andre operand ved å legge den signerte forskyvningsfeltverdien til innholdet i det generelle registeret spesifisert av basefeltet. I en utførelsesform, når baseregisterfeltet er '0 ', er tegnet utvidet verdien av forskyvningsfeltet brukes direkte til å angi andre operand. Når STORE SYSTEM INFORMASJON instruksjonen hentes og kjøres, avhengig av en funksjonskodes generelle register 0, enten en identifisering av nivået på konfigurasjonsutførelsesprogrammet er plassert i generelt register 0 eller informasjon om en komponent eller komponenter til en konfigurasjon er lagret i en system-informasjon blokk (SYSIB). Når informasjonen om en komponent eller komponenter blir bedt om, er informasjon spesifisert av ytterligere innhold av generelt register 0 og av innholdet av generelt register 1. SYSIB, hvis noen, er utpekt av andreoperand adressen. Maskinen er vurdert å gi ett, to eller tre nivåer av konfigurasjonen. Nivåene er: 1. Den grunnleggende maskinen, som er den maskinen som om den var i drift i standardmodus. 2. En logisk partisjon, som om dersom maskinen er i drift i LPAR (logisk partisjonert) modus. En logisk partisjon er levert av LPAR hypervisor, som er en del av maskinen. En grunnleggende maskin finnes selv når maskinen er i drift i LPAR modus.