Il giorno lunedì 10 luglio 2017 20:41:23 UTC+2, Roman Leventov ha scritto: > > On 10 July 2017 at 13:21, Martin Thompson <mjp...@gmail.com <javascript:>> > wrote: > >> Are you running recent MacOS with APFS which supports sparse files? >> > > If this is of any interest, my OS version is > > Darwin MacBook-Pro.local 16.6.0 Darwin Kernel Version 16.6.0: Fri Apr 14 > 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64 > > (i. e. very recent) > > When considering an algorithm for pre-touch ahead it is often useful to >> consider rate to determine who far ahead you should be pre-touching. >> > > Logically the higher the rate the longer pre-touch chunk should be, but > when I did pretouch of the whole 32 MB buffers (instead of 1 MB chunks) > pauses were even worse. > > >> When pre-touching then it can be better with a positional write of a >> byte, i.e. use >> https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileChannel.html#write(java.nio.ByteBuffer,%20long) >> >> which should map to pwrite() on Linux. This will be a safepoint whereas the >> mapped buffer write will not be. >> > > Thanks, will try >
Most results depends on: - the MMU/TLB is shared between the cores? (if not maybe using a different thread/core could make the things worse) - as Mr T. and others pointed...write back and I/O (and file system too) effects need to be repeatible - maybe Peter L. has already done something similar here: https://github.com/OpenHFT/Chronicle-Queue/blob/80fad7711bc5b5ebd0a78a44f7459d65139b8e32/src/main/java/net/openhft/chronicle/queue/impl/single/PretoucherState.java - the order of pretouch could change the results (descending or not) due to LRU eviction policies of the page cache -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
