On Fri, May 23, 2014 at 01:44:09AM +0200, Samuel Thibault wrote: > Richard Braun, le Mon 05 May 2014 18:32:26 +0200, a écrit : > > On Mon, May 05, 2014 at 06:01:17PM +0200, Samuel Thibault wrote: > > > ? The patch makes both ext2fs's service_paging_requests and libdiskfs' > > > service_paging_requests become singlethreaded. > > > > That's what I call the paging part. The front side, where client calls > > are processed, is still multithreaded, which is what really matters. > > But the paging part also comes from client events, doesn't it? E.g. > on-demand loads of parts of mapped libraries, etc.
If on-demand here means on page fault, then no. In Mach, client threads don't process their page faults, the kernel merely sends async requests to external pagers. There is normally no I/O when the underlying physical pages are already resident. External pagers are used only when I/O must be done, in which case a single thread per backing device is fine since processing incoming requests is normally orders of magnitude faster than the underlying device latency. Note that one of the future directions of the thread migration paper [1] was about making client threads service their own page faults. The two advantages of this strategy that I can think of are 1/ concurrency in diskless file systems where I/O latency can actually be very low and 2/ maintaining scheduling properties. We could use a multithreaded pool to help case 1/, and 2/ actually doesn't matter that much since scheduling properties are most important to real time applications, which are supposed to lock memory in anyway, but it's better for processor time accounting nonetheless. -- Richard Braun [1] http://www.bford.info/pub/os/thread-migrate.pdf
