I managed to implement my change to make msf_read() use device strategy routing directly to bulk read however many blocks at once the uio parameter to mfs_read() specifies and as expected now the java run takes ~ 850 ms (down from 3500-4500ms). Which means it still spends ~600 ms reading ~ 14MB of data.
So in general my thinking was correct. On Tue, Nov 21, 2017 at 6:12 PM, Nadav Har'El <n...@scylladb.com> wrote: > > On Tue, Nov 21, 2017 at 3:43 PM, Waldek Kozaczuk <jwkozac...@gmail.com> > wrote: > >> >> I am still interested how to make OSv page manager to request multiple >> pages. >> > > It's been a while since I touched any of this code :-( > > Unfortunately it's not yet clear to me how to do this cleanly. We could > change file_vma::fault() (in mmu.cc) to instead of using size = page_size, > use something higher, but I think this would still generate - through all > the templates - separate 4K reads. > We could check that by forcing map_populate (e.g., in map_file() in > mmu.cc, unconditionally do the populate_vma). I'm worried that even then, > we would get 4K reads, not anything bigger, because the population code > loops over pages. But it's worth trying. > > I think (?) what the existing ZFS code does is to have the ZFS code read a > lot of the file into its own memory pages, and then some code just points > to those pages on a page fault, but I still haven't found where this code > actually is. > > Nadav. > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
