Madvise (___, ___, MADV_DONTNEED) istruisce il sistema operativo a scrivere pigramente sul disco?

Question

Ipoteticamente, supponiamo di voler eseguire la scrittura sequenziale su un file potenzialmente molto grande.

Se I mmap() è una regione gigantesca e madvise (MADV_SEQUENTIAL) in tutta la regione, posso scrivere in memoria in modo relativamente efficiente. Questo ho ottenuto di lavorare bene.

Ora, per liberare varie risorse del sistema operativo mentre sto scrivendo, eseguo occasionalmente un munmap() su piccoli pezzi di memoria che sono già stati scritti. La mia preoccupazione è che munmap() e msync() blocchino il mio thread, in attesa che i dati vengano fisicamente trasferiti sul disco. Non posso affatto rallentare il mio scrittore, quindi ho bisogno di trovare un altro modo.

Sarebbe meglio usare madvise (MADV_DONTNEED) sul piccolo blocco di memoria già scritto? Voglio dire al sistema operativo di scrivere quella memoria sul disco pigramente, e non per bloccare il mio thread chiamante.

La pagina di manuale su madvise() ha questo da dire, che è piuttosto ambigua:

MADV_DONTNEED 
Do not expect access in the near future. (For the time being, the 
application is finished with the given range, so the kernel can free 
resources associated with it.) Subsequent accesses of pages in this 
range will succeed, but will result either in re-loading of the memory 
contents from the underlying mapped file (see mmap(2)) or 
zero-fill-on-demand pages for mappings without an underlying file. 

Answer 1

prima, madv_sequential consente readahead aggressivo, in modo che non ne hai bisogno. in secondo luogo, os scriverà pigramente su disco la memoria sporca di file sul disco, anche se non farai nulla. ma madv_dontneed lo istruirà a liberare memoria immediatamente (ciò che chiamate "varie risorse os"). terzo, non è chiaro che i file mmapping per la scrittura sequenziale abbiano qualche vantaggio. probabilmente starai meglio scrivendo semplicemente (2) (ma usa i buffer - sia manuale che stdio).

Answer 2

No!

Per il tuo bene, stare lontano da MADV_DONTNEED. Linux sarà non prendere questo come suggerimento per buttare via le pagine dopo averle scritte di nuovo, ma per buttarle via immediatamente. Questo non è considerato un bug, ma una decisione deliberata.

Paradossalmente, il ragionamento è che la funzionalità di un non distruttivo MADV_DONTNEED è già dato da msync(MS_INVALIDATE|MS_ASYNC), MS_ASYNC invece non inizia I/O (in realtà, non fa nulla, seguendo il ragionamento che sporca writeback della pagina funziona comunque), fsync blocca sempre e sync_file_rangepuò bloccare se si supera un limite oscuro ed è considerato "estremamente pericoloso" dalla documentazione, qualunque cosa ciò significhi.

In entrambi i casi, è necessario msync(MS_SYNC), o fsync (entrambi blocco), o sync_file_range (possibilmente blocco) seguita da fsync, o si si perdere i dati con MADV_DONTNEED. Se non puoi permetterti di bloccare, non hai scelta, purtroppo, ma per farlo in un altro thread.