i'm not sure i understand even the most abstract topic discussed here, what's the advantage of logically organizing your data in size constrained unnamed page tables as opposed to files in a named tree?
in the end you are assuming your memloads are not gonna be translated into some message passing protocol underneath? are you sure you can treat all your big data like one continuous memory region? "The main benefits of mmap are reduced initial latency" -> latency from where to where? what kind information are you transmitting in that procedure? what concrete problem are you trying to solve? On Wed, Feb 11, 2026 at 4:34 AM Ori Bernstein <[email protected]> wrote: > On Tue, 10 Feb 2026 05:13:47 -0500 > "Alyssa M via 9fans" <[email protected]> wrote: > > > On Monday, February 09, 2026, at 3:24 PM, ron minnich wrote: > > > as for mmap, there's already a defacto mmap happening for executables. > They are not read into memory. In fact, the first instruction you run in a > binary results in a page fault. > > I thinking one could bring the same transparent/defacto memory mapping > to read(2) and write(2), so the API need not change at all. > > That gets... interesting, from an FS semantics point of view. > What does this code print? Does it change with buffer sizes? > > fd = open("x", ORDWR); > pwrite(fd, "foo", 4, 0); > read(fd, buf, 4); > pwrite(fd, "bar", 4, 0); > print("%s\n", buf); > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te8d7c6e48b5c075b-M8565c9f999a17aefbdadb48b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
