Re: paging behavior in Linux

From: Andrew Morton (
Date: Wed Feb 28 2001 - 18:00:38 EST

David Mansfield wrote:
> Manfred Spraul wrote:
> >
> > >
> > > When I run my program on a readhat linux machine, I dont get results as
> > > expected, work thread seems to be stuck when prefetch thread is waiting on
> > > a page fault
> > >
> > That's a known problem:
> >
> > The paging io for a process is controlled with a per-process semaphore.
> > The semaphore is held while waiting for the actual io. Thus the paging
> > in multi threaded applications is single threaded.
> > Probably your prefetch thread is waiting for disk io, and the worker
> > thread causes a minor pagefault --> worker thread sleeps until the disk
> > io is completed.
> This behavior is actually pretty annoying. There can be cases where a
> process wakes up from a page fault, does some work, goes back to sleep
> on a page fault, thereby keeping it's mmap_sem locked at all times (i.e.
> vmstat, top, ps unusable) on a UP system. I posted this complaint a
> while ago, it was discussed by Linus and Andrew Morton about how it also
> boiled down to semaphore wakeup unfairness (and bugs?). The current
> semaphore was determined to be too ugly to even look at. So it was
> dropped.
> Is there any way that the mmap_sem could be dropped during the blocking
> on I/O, and reclaimed after the handle_mm_fault? Probably not, or it'd
> be done.
> It can be a real DOS though, a 'well-written' clobbering program can
> make ps/vmstat useless. (it's actually /proc/pid/stat that's the
> killer, IIRC).

Did the `goto inside' trick in the semaphore code actually
fix this unfairness issue?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Feb 28 2001 - 21:00:17 EST