All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Mansfield <lkml@dm.ultramaster.com>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: neelam_saboo@usa.net, linux-kernel@vger.kernel.org
Subject: Re: paging behavior in Linux
Date: Wed, 28 Feb 2001 16:54:10 -0500	[thread overview]
Message-ID: <3A9D7382.A020354E@dm.ultramaster.com> (raw)
In-Reply-To: <3A9D6F05.F24D5558@colorfullife.com>

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).

David

-- 
David Mansfield                                           (718) 963-2020
david@ultramaster.com
Ultramaster Group, LLC                               www.ultramaster.com

  reply	other threads:[~2001-02-28 21:54 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 [this message]
2001-02-28 23:00   ` Andrew Morton
  -- 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=3A9D7382.A020354E@dm.ultramaster.com \
    --to=lkml@dm.ultramaster.com \
    --cc=linux-kernel@vger.kernel.org \
    --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.