Sidecache-cacher nyligt åbnede sider fra harddisken, hvilket reducerer søgetiden for efterfølgende adgang til de samme data. Sidecachen forbedrer ikke ydeevnen, første gang en side åbnes fra harddisken. Så hvis en app skal læse en fil en gang og kun én gang, er det den bedre vej at gå uden om sidecachen. Dette er muligt ved at bruge O_DIRECT flaget. Det betyder, at kernen ikke tager hensyn til disse særlige data til sidecachen. Reduktion af cache-strid betyder, at andre sider (som ville blive tilgået gentagne gange) har en bedre chance for at blive bevaret i sidecachen. Dette forbedrer cache-hit-forholdet, hvilket giver bedre ydeevne.
void ioReadOnceFile()
{
/* Brug af direct_fd og direct_f omgår kernens sidecache.
* - direct_fd er en filbeskrivelse
på lavt niveau* - direct_f er en filstrøm, der ligner en, der returneres af fopen()
* BEMÆRK: Brug getpagesize() til at bestemme buffere i optimal størrelse.
*/
int direct_fd = open("filnavn", O_DIRECT | O_RDWR);
FIL *direct_f = fdopen(direct_fd, "w+");
/* direkte disk-I/O udført HER*/
Fluk(F);
luk(fd);
}
Overvej tilfældet med en læsning i en stor fil (dvs. en database) lavet af et stort antal sider. Hver efterfølgende side, der åbnes, går ind i sidecachen kun for at blive droppet ud senere, efterhånden som flere og flere sider læses. Dette reducerer cache-hit-forholdet alvorligt. I dette tilfælde giver sidecachen ingen præstationsgevinster. Derfor ville man være bedre stillet ved at omgå sidecachen, når man får adgang til store filer.
void ioLargeFile()
{
/* Brug af direct_fd og direct_f omgår kernens sidecache.
* - direct_fd er en filbeskrivelse
på lavt niveau* - direct_f er en filstrøm, der ligner en, der returneres af fopen()
* BEMÆRK: Brug getpagesize() til at bestemme buffere i optimal størrelse.
*/
int direct_fd = åben("largefile.bin", O_DIRECT | O_RDWR | O_LARGEFILE);
FIL *direct_f = fdopen(direct_fd, "w+");
/* direkte disk-I/O udført HER*/
Fluk(F);
luk(fd);
}
IO-planlæggeren optimerer rækkefølgen af I/O-handlinger, der skal sættes i kø på harddisken. Da søgetiden er den hårdeste straf på en harddisk, forsøger de fleste I/O-planlæggere at minimere søgetiden. Dette implementeres som en variant af elevatoralgoritmen, dvs. ombestilling af tilfældigt bestilte anmodninger fra adskillige processer til den rækkefølge, hvor dataene er til stede på harddisken, kræver en betydelig mængde CPU-tid.
Visse opgaver, der involverer komplekse operationer, har tendens til at være begrænset af, hvor hurtigt CPU'en kan behandle store mængder data. En kompleks I/O-scheduler, der kører i baggrunden, kan forbruge kostbare CPU-cyklusser og derved reducere systemets ydeevne. I dette tilfælde reducerer skift til en enklere algoritme som no-op CPU-belastningen og kan forbedre systemets ydeevne.
ekko noop > / sys / blok / / kø / scheduler
Selvom dette i sidste ende vil få arbejdet gjort, er det bestemt ikke den mest optimale måde. Fra kernens perspektiv er den mest optimale størrelse for I/O-anmodninger filsystemets blokstørrelse (dvs. sidestørrelsen). Da alle I/O i filsystemet (og kernens sidecache) er i form af sider, giver det mening for appen også at foretage overførsler i multipla af sidestørrelse. Også med multi-segmenterede cacher, der gør deres vej ind i harddiske nu, ville man enormt drage fordel af at gøre I / O i multipla af blokstørrelse.
Følgende kommando kan bruges til at bestemme den optimaleblokstørrelsesstat --printf="bs=%s optimal-bs=%S\n" --file-system /dev/
Når en app starter en SYNC I/O-læsning, sætter kernen en læsehandling i kø for dataene og vender først tilbage, når hele blokken af anmodede data er læst tilbage. I denne periode markerer kernen programmets proces som blokeret for I/O. Andre processer kan bruge CPU'en, hvilket resulterer i en generelt bedre ydeevne for systemet.
Når en app starter en SYNC I/O-skrivning, sætter kernen en skrivehandling i kø for dataene og sætter programmets proces i en blokeret I/O. Desværre betyder det, at den aktuelle applikationsproces er blokeret og ikke kan udføre nogen anden behandling (eller I / O for den sags skyld), før denne skrivehandling er afsluttet.
Når en app starter en ASYNC I/O-læsning, vender read()-funktionen normalt tilbage efter at have læst et undersæt af den store datablok. Appen skal gentagne gange kalde read() med størrelsen af de data, der mangler at blive læst, indtil alle nødvendige data er indlæsning. Hvert ekstra kald, der skal læses, introducerer nogle omkostninger, da det introducerer et kontekstskift mellem brugerrummet og kernen. Implementering af en stram løkke til gentagne gange at kalde read() spilder CPU-cyklusser, som andre processer kunne have brugt. Derfor implementerer man normalt blokering ved hjælp af select(), indtil næste read() returnerer ikke-nul bytes indlæsning. dvs. ASYNC er lavet til at blokere ligesom SYNC-læsningen gør.
Når en app starter en ASYNC I/O-skrivning, opdaterer kernen de tilsvarende sider i sidecachen og markerer dem som beskidte. Derefter vender kontrolelementet hurtigt tilbage til appen, som kan fortsætte med at køre. Dataene skylles senere til harddisken på et mere optimalt tidspunkt (lav CPU-belastning) på en mere optimal måde (sekventielt bundtede skrivninger).
Derfor er SYNC-reads og ASYNC-writes generelt en god vej at gå, da de giver kernen mulighed for at optimere rækkefølgen og timingen af de underliggende I/O-anmodninger.