Linux Kernel x32-arkitektur kan avvikles

Linux Kernel 4.19

Nylig en e-post ble utgitt gjennom Linux Kernel-postlisten, og denne e-postadressen har som hovedmål fjern koden fra implementeringen av underarkitekturen x32 (ikke forveksles med x86 IA-32).

Som lar deg bruke 32-biters adresseringsmodell (hybrid x86 og x86_64) på ​​x86 64-biters systemer.

Hva er x32-arkitekturen?

Det er viktig å nevne at x32-underarkitekturen er en hybrid x86_64 ABI, som lar en 32-biters adresseringsmodell brukes på 64-biters systemer (prosessoren fungerer i 64-biters modus, men bruker 32-biters pekere og aritmetiske operasjoner).

ABI X32 lar applikasjoner dra full nytte av x86_64-arkitekturen, for eksempel tilleggsregistre og raskere instruksjoner, PIC ABI.

Samtidig støtter ABI X32 32-biters minnepekere, noe som sparer minne, bidrar til mer effektiv fylling av prosessorbufferen og har en positiv effekt på den totale hastigheten på kodeutførelsen.

Begrensningen med ABI X32 er umuligheten av å lede mer enn 4 GB minne fra applikasjonen.

X32-støtte har vært en del av Linux-kjernen siden 3.4-utgivelsen, dannet i mai 2012.

Utviklere vil diskutere om de vil fortsette å vedlikeholde denne arkitekturen eller ikke

Ifølge utvikler foreslår fjerning av x32-teknologi det har ikke vært berettiget og har ikke funnet en praktisk anvendelse i moderne industrielle oppsett.

Dessuten, ogl x32-koden bruker ganske kontroversiell metode for å jobbe med systemanrop, som skaper risiko for å avbryte normal drift etter behandling av systemanropsimplementeringene.

Linus Torvalds sa at han ville godta å fjerne x32 hvis ingen argumenter blir levert eller hvis systemene der x32-underarkitekturen er brukt, ikke presenteres.

Linus bemerket også at bruken av x32-arkitekturen tilsynelatende var begrenset til ekstreme ytelsestesters, siden støtten til denne underarkitekturen er forbundet med mange komplikasjoner for å opprettholde distribusjonene og utviklingsmiljøet.

Posten:

Hei alle sammen.

Jeg vurderer seriøst å sende inn en oppdatering for å fjerne x32-støtte fra Linux. Her er noen problemer med dette:

  1. Det er ikke helt klart at det har brukere. Så vidt jeg vet støttes det av Gentoo og Debian
  2. Måten anropssystemet fungerer på er veldig rart. De fleste syscalls på x32 kommer inn via deres * native * (dvs. ikke COMPAT_SYSCALL_DEFINE) med inngangspunktet, og dette er forsettlig.

For eksempel bruker adjtimex () den opprinnelige inngangen, ikke kompat-inngangen, fordi x32 struct timex samsvarer med x86_64-oppsettet. Men en håndfull syscalls har separate inngangspunkter - dette er syscalls som starter på 512.

Disse går inn gjennom inngangspunktene COMPAT_SYSCALL_DEFINE.

X32-syscalls som * ikke * er i 512-området, bryter med alle skinn i kjernekonvensjonen.

I syscall-håndterere returnerer in_compat_syscall () true, men oppføringen COMPAT_SYSCALL_DEFINE blir ikke påkalt, dette er sinnssykt og du risikerer å ødelegge ting når folk omformer deres syscall-implementeringer.

Og fremfor alt prøver ingen disse tingene.

Ved en anledning Ved testing av x32 konkluderte en av Gentoo-utviklerne at ytelsesforbedringen når du bytter til ABI x32 ikke er så stor som de syntetiske testene viser Fra produsentene av ABI x32:

Betydelig fremgang sees bare sammenlignet med den forrige x86-arkitekturen, men når den sammenlignes med den nåværende x86-64-arkitekturen, er gevinsten ubetydelig (SPEC-tester fra skaperne av x32 viste opptil 40% akselerasjon sammenlignet med den klassiske ABI x86_64, tester med H.264-kodeken viste en akselerasjon på 15-20%).


Legg igjen kommentaren

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

*

*

  1. Ansvarlig for dataene: AB Internet Networks 2008 SL
  2. Formålet med dataene: Kontroller SPAM, kommentaradministrasjon.
  3. Legitimering: Ditt samtykke
  4. Kommunikasjon av dataene: Dataene vil ikke bli kommunisert til tredjeparter bortsett fra ved juridisk forpliktelse.
  5. Datalagring: Database vert for Occentus Networks (EU)
  6. Rettigheter: Når som helst kan du begrense, gjenopprette og slette informasjonen din.