From: Andrew Morton <andrewm@uow.edu.au>
To: David Mansfield <lkml@dm.ultramaster.com>
Cc: Manfred Spraul <manfred@colorfullife.com>,
neelam_saboo@usa.net, linux-kernel@vger.kernel.org
Subject: Re: paging behavior in Linux
Date: Wed, 28 Feb 2001 23:00:38 +0000 [thread overview]
Message-ID: <3A9D8316.24D6BA42@uow.edu.au> (raw)
In-Reply-To: <3A9D6F05.F24D5558@colorfullife.com> <3A9D7382.A020354E@dm.ultramaster.com>
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?
-
next prev parent reply other threads:[~2001-02-28 23:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-28 21:35 paging behavior in Linux Manfred Spraul
2001-02-28 21:54 ` David Mansfield
2001-02-28 23:00 ` Andrew Morton [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-02-28 17:58 Neelam Saboo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A9D8316.24D6BA42@uow.edu.au \
--to=andrewm@uow.edu.au \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@dm.ultramaster.com \
--cc=manfred@colorfullife.com \
--cc=neelam_saboo@usa.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.