Page-cache cacher nylig åpnede sider fra harddisken, og reduserer dermed søketider for påfølgende tilgang til de samme dataene. Sidebufferen forbedrer ikke ytelsen første gang en side åpnes fra harddisken. Så hvis en app skal lese en fil en gang og bare én gang, er det bedre å omgå sidebufferen. Dette er mulig ved å bruke O_DIRECT-flagget. Dette betyr at kjernen ikke vurderer disse dataene for sidebufferen. Redusere cache-strid betyr at andre sider (som ville bli besøkt gjentatte ganger) har en bedre sjanse til å bli beholdt i side-cache. Dette forbedrer treffforholdet for hurtigbufferen og gir bedre ytelse.
void ioReadOnceFile()
{
/* Bruk av direct_fd og direct_f omgår kjerneside-cache.
* - direct_fd er en filbeskrivelse
på lavt nivå* - direct_f er en filstrøm som ligner på en returnert av fopen()
* MERK: Bruk getpagesize() for å bestemme buffere av optimal størrelse.
*/
int direct_fd = åpen("filnavn", O_DIRECT | O_RDWR);
FIL *direct_f = fdopen(direct_fd, "w+");
/* direkte disk-I/O gjort HER*/
fclose(f);
lukk(fd);
}
Tenk på tilfellet med en lesing i en stor fil (dvs. en database) laget av et stort antall sider. Hver påfølgende side som åpnes, går inn i sidebufferen bare for å bli droppet ut senere etter hvert som flere og flere sider blir lest. Dette reduserer forholdet mellom hurtigbuffer og treff kraftig. I dette tilfellet gir sidebufferen ingen ytelsesgevinster. Derfor ville det være bedre å omgå sidebufferen når man får tilgang til store filer.
void ioLargeFile()
{
/* Bruk av direct_fd og direct_f omgår kjerneside-cache.
* - direct_fd er en filbeskrivelse
på lavt nivå* - direct_f er en filstrøm som ligner på en returnert av fopen()
* MERK: Bruk getpagesize() for å bestemme buffere av optimal størrelse.
*/
int direct_fd = åpen("largefile.bin", O_DIRECT | O_RDWR | O_LARGEFILE);
FIL *direct_f = fdopen(direct_fd, "w+");
/* direkte disk-I/O gjort HER*/
fclose(f);
lukk(fd);
}
I/O-planleggeren optimaliserer rekkefølgen på I/O-operasjoner som skal settes i kø til harddisken. Siden søketid er den tyngste straffen på en harddisk, prøver de fleste I/O-planleggere å minimere søketiden. Dette implementeres som en variant av heisalgoritmen, dvs. ombestilling av tilfeldig bestilte forespørsler fra mange prosesser til rekkefølgen der dataene er til stede på harddisken, krever en betydelig mengde CPU-tid.
Enkelte oppgaver som involverer komplekse operasjoner har en tendens til å være begrenset av hvor raskt CPU-en kan behandle store mengder data. En kompleks I/O-planlegger som kjører i bakgrunnen, kan bruke dyrebare CPU-sykluser og dermed redusere systemytelsen. I dette tilfellet reduserer bytte til en enklere algoritme som no-op CPU-belastningen og kan forbedre systemytelsen.
echo noop > /sys/block//queue/scheduler
Selv om dette til slutt vil få jobben gjort, er det definitivt ikke den mest optimale måten. Fra kjernens perspektiv er den mest optimale størrelsen for I/O-forespørsler størrelsen på filsystemets blokkstørrelse (dvs. sidestørrelsen). Siden all I / O i filsystemet (og kjernesidens cache) er når det gjelder sider, er det fornuftig for appen å gjøre overføringer i multipler av sidestørrelse også. Også med multi-segmenterte cacher på vei inn i harddisker nå, vil man ha stor nytte av å gjøre I / O i multipler av blokkstørrelse.
Følgende kommando kan brukes til å bestemme den optimaleblokkstørrelsesstatistikken --printf="bs=%s optimal-bs=%S\n" --file-system /dev/
Når en app starter en SYNC I/O-lesing, setter kjernen en leseoperasjon for dataene i kø og returnerer først etter at hele blokken med forespurte data er lest tilbake. I løpet av denne perioden vil kjernen merke applikasjonens prosess som blokkert for I/O. Andre prosesser kan bruke CPU, noe som resulterer i en generelt bedre ytelse for systemet.
Når en app starter en SYNC I/O-skriving, setter kjernen en skriveoperasjon for dataene i kø applikasjonsprosessen i en blokkert I/O. Dessverre betyr dette at prosessen til det gjeldende programmet er blokkert og ikke kan gjøre noen annen behandling (eller I / O for den saks skyld) før denne skriveoperasjonen er fullført.
Når en app starter en ASYNC I/O-lesing, returneres read()-funksjonen vanligvis etter å ha lest et delsett av den store datablokken. Appen må gjentatte ganger ringe read() med størrelsen på dataene som gjenstår å bli lest, til alle nødvendige data er lest. Hvert ekstra kall for å lese introduserer noen overhead da det introduserer en kontekstbryter mellom brukerområdet og kjernen. Implementering av en stram sløyfe for å gjentatte ganger kalle read() kaster bort CPU-sykluser som andre prosesser kunne ha brukt. Derfor implementerer man vanligvis blokkering ved hjelp av select() til neste read() returnerer ikke-null byte read-in. dvs. ASYNC er laget for å blokkere akkurat som SYNC-lesingen gjør.
Når en app starter en ASYNC I/O-skriving, oppdaterer kjernen de tilsvarende sidene i sidebufferen og markerer dem som skitne. Deretter går kontrollen raskt tilbake til appen som kan fortsette å kjøre. Dataene skylles til harddisken senere på et mer optimalt tidspunkt (lav CPU-belastning) på en mer optimal måte (sekvensielt samlet skriveoperasjoner).
Derfor er SYNC-reads og ASYNC-writes generelt en god vei å gå, da de lar kjernen optimalisere rekkefølgen og tidspunktet for de underliggende I / O-forespørslene.