On POSIX, mmap objects could expose a method wrapping the madvise() library call. I suggest the following API mmap_object.madvise(option[, start[, length]]) If omitted, *start* and *length* would span the whole memory area described by the mmap object. *option* must be a recognized OS option for the madvise() library call. The mmap module would expose the various MADV_* options available on the current platform. Open question: should we expose madvise() or posix_madvise()? (these are two different calls, at least on Linux) posix_madvise() is arguably more portable, but madvise() is much more powerful, so I'd lean towards madvise().
It might be nice to expose a more limited API to prefetch memory in bulk while we're at it. Windows 8 and higher offers PrefetchVirtualMemory ( https://docs.microsoft.com/en-us/windows/desktop/api/memoryapi/nf-memoryapi-prefetchvirtualmemory ) which fills roughly the same niche as madvise/posix_madvise with the WILLNEED hint. I kept meaning to file an issue to suggest this, but kept getting hung up on how to make it as portable as possible and as powerful as possible, and where to implement it. It could go on mmap, but it's also useful for just about any contiguous buffer-supporting object, so it almost seems like adding an os.madvise (and/or os.prefetch) would make more sense than specifically tying it to the mmap module.
Josh, sorry, I hadn't seen your message. Those are low-levels operations, so I don't know if it makes sense to implement madvise() in terms of PrefetchVirtualMemory(), or expose a separate wrapper to PrefetchVirtualMemory(). One complication is that we currently don't expose public wrappers over Windows API functions (there's a private _winapi module).
