L'esecuzione su tmpfs sarà più veloce solo se hai un sacco di I/O su disco che non viene soddisfatto dalla cache della pagina.
Se l'I/O viene letto e i file sono già nella cache, tmpfs non farà alcuna differenza.
Se l'I/O è scritture asincrone senza svuotamento e il carico di lavoro è esplosivo anziché continuo e c'è abbastanza cache per assorbire un burst di scritture e le scritture possono essere scaricate in background tra i burst, tmpfs non farà alcuna differenza.
Se non c'è alcun I/O su disco da eseguire, tmpfs non farà alcuna differenza.
Se hai un sacco di I/O su disco e il tuo processo è bloccato in attesa che l'archiviazione recuperi, l'esecuzione su tmpfs farà un'enorme differenza. Più lenti sono i tuoi dischi, maggiore sarà la differenza, fino al punto in cui diventerai un collo di bottiglia della CPU.
(4) L'eseguibile viene eseguito all'interno di un contenitore Docker e l'eseguibile e tutti i file coinvolti si trovano in una cartella tmpfs creata all'interno del contenitore, in un'unità "interna" (che non persiste dopo l'arresto del contenitore).
(5) L'eseguibile viene eseguito all'interno di un contenitore Docker e l'eseguibile e tutti i file coinvolti si trovano in cartelle del disco "normali".
Tmpfs a parte (che è già stato risolto) non noterai alcuna differenza tra l'esecuzione di eseguibili sull'host e all'interno di un contenitore Docker. Lo stesso con l'archiviazione del volume. Docker esegue entrambi utilizzando un file system overlay e probabilmente c'è un molto piccolo calo delle prestazioni per l'overlay ma l'host vede l'eseguibile in esecuzione come un processo proprio come se fosse stato avviato sull'host.
Realisticamente, dovrebbe esserci una differenza quasi nulla o nulla. Potrebbero esserci validi motivi per fare una cosa del genere, ma oserei dire che per il 99,9% di tutti i casi si tratta di un'anti-ottimizzazione.
L'I/O normale andrà alla cache del buffer e le pagine sporche verranno scritte in modo asincrono da un thread del kernel. Larghezza di banda =velocità della RAM, ritardo =ritardo della RAM (più, forse qualche µs per un errore di pagina qua e là).
Quando il sistema esaurisce la RAM fisica, bloccherai (ovviamente), non c'è altro modo. Quando non ci sono più pagine su cui puoi scrivere, dovrai aspettare che alcune vengano liberate. Non c'è altro modo.
L'esaurimento della RAM è, tuttavia, per definizione, improbabile (o possibile) che si verifichi nel tuo caso particolare. Altrimenti, se c'è una reale possibilità di esaurire la RAM, l'idea di creare un tmpfs sarebbe piuttosto stupida in primo luogo.
L'I/O a tmpfs andrà a... la cache del buffer. Sì, ora funziona con un nome diverso, ma in realtà è esattamente lo stesso, grazie al sistema VM unificato. La larghezza di banda e il ritardo sono quindi esattamente gli stessi (dare o prendere forse l'1% di differenza a causa delle sottigliezze del filesystem che potrebbero essere leggermente diverse). Non è in corso alcun writeback, sì. Ma a chi importa, visto come accadrebbe comunque in modo asincrono. Al contrario, ora non hai il lusso che qualcuno liberi pagine sporche in background, quindi la probabilità di raggiungere il limite massimo, se possibile, è in realtà più alta.
Quando il sistema esaurisce la RAM fisica, stai ancora scrivendo solo su pagine mappate in memoria, quindi in teoria dovresti essere in grado di farlo più velocemente. Tuttavia, in pratica, c'è ancora solo tanta RAM fisica, e l'hai appena esaurita! Certo, potrebbe esserci ancora spazio nel tuo tmpfs, ma per qualche motivo, anche altrimenti è necessario scrivere una pagina di memoria e non ne rimane nessuna.
Quindi il kernel deve fare qualcosa per mantenere il sistema in funzione. Deve in qualche modo riorganizzare le sue risorse per mitigare il problema (possibilmente scambiare il processo docker e l'intero contenitore?!). Il kernel si sforzerà, ma non è che possa fare magie, deve fare qualcosa , e le sue scelte sono limitate. Tanto più che hai deliberatamente portato via un numero enorme di pagine che potrebbe altrimenti utilizzare liberamente secondo necessità per qualsiasi scopo (inclusa la richiesta che deve essere servita in questo momento).