stack pre-impostazione in linux - sono necessari errori singoli o multipli

Question

In Linux, quando il processo richiede una memoria (virtuale) dal sistema, è appena registrato in vma (descrittore della memoria virtuale del processo) ma la pagina fisica per ogni virtual non è riservata a tempo di chiamata. In seguito, quando il processo accederà a questa pagina, verrà criticato (l'accesso genererà interrupt di errore di pagina) e il gestore PF assegna la pagina fisica e la tabella della pagina di processo di aggiornamento.

Ci sono due casi: l'errore durante la lettura può trasformarsi in un collegamento a una pagina zero (speciale pagina globale pre-azzerata) che è protetto da scrittura; e l'errore nella scrittura (sia sulla pagina zero che sulla pagina appena richiesta, ma non fisicamente mappata) si tradurrà nell'assegnazione fisica delle pagine private.

Per mmaps (e brk/sbrk, che internamente è anche mmap) questo metodo è per pagina; tutte le regioni in mmap sono registrate come interamente in vma (hanno indirizzi iniziali e finali). Ma lo stack è gestito in altro modo, perché ha solo l'indirizzo di partenza (quello più alto sulla piattaforma tipica, cresce fino agli indirizzi più bassi).

La domanda è:

Quando accedo nuova memoria non allocato nei pressi di pila, otterrà PF # e crescere. Come viene gestita questa crescita, se non accedo alla pagina accanto allo stack, ma la pagina che si trova a 10 o 100 pagine dallo stack?

E.g.

int main() { 
    int *a = alloca(100); /* some useful data */ 
    int *b = alloca(50*4096); /* skip 49 pages */ 
    int *c = alloca(100); 

    a[0]=1; 
/* no accesses to b - this is untouched hole of 49 pages */ 
    c[0]=1; 

} 

Questo programma riceverà 2 o 50 pagine fisiche private allocate per stack?

Penso che possa essere proficuo chiedere al kernel di allocare decine di pagine fisiche in un'unica pagina di default quindi fare decine di pagine che assegnano pagina per pagina (1 interrupt + 1 context-switch + semplice, cache-friendly loop su N richieste di allocazione di pagina contro N interruzioni + N interruttori di contesto + N allocazioni di pagina, quando il codice mm può essere rimosso da Icache).

Answer 1

La coltivazione automatica della pila può essere pensato chiamate come automatici mremap per ridimensionare l'area dell'indirizzo virtuale che conta come "stack". Una volta che viene gestito, i page fault nell'area dello stack o in una regione di mmap vanilla vengono gestiti allo stesso modo, cioè una pagina alla volta.

Così si dovrebbe finire con ~ 2 pagine allocate, non ~ 51. La risposta empirica di @perreal convalida questo ...

Per l'ultima parte della domanda, il costo di errori di pagina contigui è uno dei fattori che portano allo sviluppo di "pagine enormi". Non credo che ci siano altri modi in Linux per "gestire" la gestione degli errori di pagina. Forse madvise potrebbe fare qualcosa, ma ho il sospetto che ottimizzi soprattutto la parte molto costosa degli errori di pagina che sta cercando le pagine di supporto sullo storage). Gli errori di pagina dello stack che mappano a zero pagine sono relativamente leggeri al confronto.

Answer 2

Con questo codice:

int main() { 
    int *a = alloca(100); /* some useful data */ 
    int *b = alloca(50*4096); /* skip 49 pages */ 
    int *c = alloca(100); 
    int i; 
#if TOUCH > 0 
    a[0] = 1;    // [1] 
#endif 
#if TOUCH > 1 
    c[0] = 1;    // [2] 
#endif 
#if TOUCH > 2 
    for (i=0; i<25; i++) // [3] 
    b[i*1024] = 1; 
#endif 
#if TOUCH > 3 
    for (i=25; i<50; i++) // [4] 
    b[i*1024] = 1; 
#endif 
    return 0; 
} 

E questo script:

for i in 1 2 3 4; do 
    gcc d.c -DTOUCH=$i 
    echo "Upto [$i]" $(perf stat ./a.out 2>&1 | grep page-faults) 
done 

L'output:

Upto [1] 105 page-faults # 0.410 M/sec 
Upto [2] 106 page-faults # 0.246 M/sec 
Upto [3] 130 page-faults # 0.279 M/sec 
Upto [4] 154 page-faults # 0.290 M/sec