since you give no reasons yourself, let me try to hallucinate a reason why you might be doing what you're doing here:
the basic assumption is that all your data is spread over multiple pages, but there is data locality per page (i.e. read/write access in one page will rarely depend on another page) maybe you could have a /dev/mem/pages so that pages become easier to access... still, no memmap needed. you just want pages to be less transparent it seems. On Sun, Feb 15, 2026 at 6:43 AM Bakul Shah via 9fans <[email protected]> wrote: > > On Feb 12, 2026, at 12:37 AM, Alyssa M via 9fans <[email protected]> wrote: > > > So what I'm suggesting is that instead of the programmer making an mmap call, > they should make a single read call to read the entire file into the address > space - as they did before. The new read implementation would do this, but as > a memory mapped snapshot. This looks no different to the programmer from how > reads have always worked, it just happens very quickly, because no I/O > actually happens. > The snapshot data is brought in by demand paging as it is touched, and pages > may get dirtied. > > > The issue here is the read call is given a pre-allocated buffer. What you > seem to want is the read call to return as soon as possible and pages get > read in when accessed. For this to work, the kernel side read implementation > has to free up (or set aside) these pages, invalidate pagetable entries & > flush relevant TLB entries & later reverse this operation once a page is > filled in. > > It is better if you let the read call itself manage memory. This was explored > in a 1994 paper: "The Alloc Stream Facility": > https://www.eecg.toronto.edu/~stumm/Papers/Krieger-IEEEComputer94.pdf > For example, > > stream = Sopen(filename, flags, ...) > ... > addr = SallocAt(stream, mode, &length, offset, whence) > // can access memory in [addr..addr+length) > Sfree(stream, addr) > ... > Sclose(stream) > > The idea is SallocAt() returns a ptr to read in data for read mode (or space > for write mode) for length amount. Actual length is returned in the length > variable if the file is too short. Sfree() frees up space or pushes out the > data to the underlying file. The alloc stream facility can in theory also use > mmap under the hood. > > One can think of mmap() as something like sallocAt() fpr page aligned data. > An added benefit: the same underlying data page can be accessed from multiple > address spaces in a similar way. Any attempt to overwrite would result in > copy-on-write so that other clients see the old data snapshot. If you want to > see any updates by other processes, you should use some higher level access > protocol to do so safely. > > Using mmap instead of read is likely less efficient but the idea is to factor > out common IO patterns. > > > > > 9fans / 9fans / see discussions + participants + delivery options Permalink ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te8d7c6e48b5c075b-Mee0c45deb26d8cc17994bfcc Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
