Re: let's make libpager single-threaded

[Richard Braun]

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