From: Andrew Morton <akpm@linux-foundation.org>
To: root@programming.kicks-ass.net
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
miklos@szeredi.hu, neilb@suse.de, dgc@sgi.com,
tomoki.sekiyama.qu@hitachi.com, a.p.zijlstra@chello.nl,
nikita@clusterfs.com
Subject: Re: [PATCH 11/12] mm: accurate pageout congestion wait
Date: Thu, 5 Apr 2007 16:17:13 -0700 [thread overview]
Message-ID: <20070405161713.dcd8bed9.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070405174320.373513202@programming.kicks-ass.net>
On Thu, 05 Apr 2007 19:42:20 +0200
root@programming.kicks-ass.net wrote:
> Only do the congestion wait when we actually encountered congestion.
The name congestion_wait() was accurate back in 2002, but it isn't accurate
any more, and you got misled. It does not only wait for a queue to become
uncongested.
See clear_bdi_congested()'s callers. As long as the queue is in an
uncongested state, we deliver wakeups to congestion_wait() blockers on
every IO completion. As I said before, it is so that the MM's polling
operations poll at a higher frequency when the IO system is working faster.
(It is also to synchronise with end_page_writeback()'s feeding of clean
pages to us via rotate_reclaimable_page()).
Page reclaim can get into trouble without any request queue having entered
a congested state. For example, think about a machine which has a single
disk, and the operator has increased that disk's request queue size to
100,000. With your patch all the VM's throttling would be bypassed and we
go into a busy loop and declare OOM instantly.
There are probably other situations in which page reclaim gets into trouble
without a request queue being congested.
Minor point: bdi_congested() can be arbitrarily expensive - for DM stackups
it is roughly proportional to the number of subdevices in the device. We
need to be careful about how frequently we call it.
next prev parent reply other threads:[~2007-04-05 23:18 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-05 17:42 [PATCH 00/12] per device dirty throttling -v3 root
2007-04-05 17:42 ` [PATCH 01/12] nfs: remove congestion_end() root
2007-04-05 17:42 ` [PATCH 02/12] mm: scalable bdi statistics counters root
2007-04-05 22:37 ` Andrew Morton
2007-04-06 7:22 ` Peter Zijlstra
2007-04-05 17:42 ` [PATCH 03/12] mm: count dirty pages per BDI root
2007-04-05 17:42 ` [PATCH 04/12] mm: count writeback " root
2007-04-05 17:42 ` [PATCH 05/12] mm: count unstable " root
2007-04-05 17:42 ` [PATCH 06/12] mm: expose BDI statistics in sysfs root
2007-04-05 17:42 ` [PATCH 07/12] mm: per device dirty threshold root
2007-04-05 17:42 ` [PATCH 08/12] mm: fixup possible deadlock root
2007-04-05 22:43 ` Andrew Morton
2007-04-05 17:42 ` [PATCH 09/12] mm: remove throttle_vm_writeback root
2007-04-05 22:44 ` Andrew Morton
2007-09-26 20:42 ` Peter Zijlstra
2007-04-05 17:42 ` [PATCH 10/12] mm: page_alloc_wait root
2007-04-05 22:57 ` Andrew Morton
2007-04-06 6:37 ` Peter Zijlstra
2007-04-05 17:42 ` [PATCH 11/12] mm: accurate pageout congestion wait root
2007-04-05 23:17 ` Andrew Morton [this message]
2007-04-06 6:51 ` Peter Zijlstra
2007-04-05 17:42 ` [PATCH 12/12] mm: per BDI congestion feedback root
2007-04-05 23:24 ` Andrew Morton
2007-04-06 7:01 ` Peter Zijlstra
2007-04-06 11:00 ` Andrew Morton
2007-04-06 11:10 ` Miklos Szeredi
2007-04-05 17:47 ` [PATCH 00/12] per device dirty throttling -v3 Peter Zijlstra
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=20070405161713.dcd8bed9.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=a.p.zijlstra@chello.nl \
--cc=dgc@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=miklos@szeredi.hu \
--cc=neilb@suse.de \
--cc=nikita@clusterfs.com \
--cc=root@programming.kicks-ass.net \
--cc=tomoki.sekiyama.qu@hitachi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox