I actually need both fadvise(...WILLNEED) and fadvise(...DONTNEED), so I could simply wrap these calls in eio_custom calls, as suggested.
On Sun, Jun 5, 2011 at 5:09 PM, Aaron Boxer <[email protected]> wrote: > Cool, thanks Marc. I will use libeio, in this case. > > So, what libeio interface should I use for this? I won't need the mmap > functionality. > > Thanks again, > Aaron > > > On Sun, Jun 5, 2011 at 4:08 PM, Marc Lehmann <[email protected]> wrote: >> On Sun, Jun 05, 2011 at 12:38:12PM -0400, Aaron Boxer <[email protected]> >> wrote: >>> This is OT, but what is the most scalable design for making such a >>> system call in a thread? >>> I am thinking: thread pool with shared queue. >> >> I don't think that's the most scalable design, but it is what libeio does. >> >>> 1) each new connection to the server will trigger a series of N fadvise >>> calls. >>> 2) the first few fadvise calls per connection should happen ASAP >>> 3) ability to re-order the fadvise calls if the client makes a >>> subsequent requests. >> >> libeio let's you queue and prioritise fadvise calls, as well as cancel >> them (as long as it isn't stuck in the kernel). >> >> libeio also has an mtouch request that can be used to implement readahead >> in userspace on mmapped files (which is currently also not cancellable >> while it executed, but could be made so). >> >> (it does not have an fadvise request, but that could be done via an >> eio_custom call). >> >> -- >> The choice of a Deliantra, the free code+content MORPG >> -----==- _GNU_ http://www.deliantra.net >> ----==-- _ generation >> ---==---(_)__ __ ____ __ Marc Lehmann >> --==---/ / _ \/ // /\ \/ / [email protected] >> -=====/_/_//_/\_,_/ /_/\_\ >> >> _______________________________________________ >> libev mailing list >> [email protected] >> http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev >> > _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
