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 10/12] mm: page_alloc_wait
Date: Thu, 5 Apr 2007 15:57:43 -0700 [thread overview]
Message-ID: <20070405155743.91380f00.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070405174320.129577639@programming.kicks-ass.net>
On Thu, 05 Apr 2007 19:42:19 +0200
root@programming.kicks-ass.net wrote:
> Introduce a mechanism to wait on free memory.
>
> Currently congestion_wait() is abused to do this.
Such a very small explanation for such a terrifying change.
> ...
>
> --- linux-2.6-mm.orig/mm/vmscan.c 2007-04-05 16:29:46.000000000 +0200
> +++ linux-2.6-mm/mm/vmscan.c 2007-04-05 16:29:49.000000000 +0200
> @@ -1436,6 +1436,7 @@ static int kswapd(void *p)
> finish_wait(&pgdat->kswapd_wait, &wait);
>
> balance_pgdat(pgdat, order);
> + page_alloc_ok();
> }
> return 0;
> }
For a start, we don't know that kswapd freed pages which are in a suitable
zone. And we don't know that kswapd freed pages which are in a suitable
cpuset.
congestion_wait() is similarly ignorant of the suitability of the pages,
but the whole idea behind congestion_wait is that it will throttle page
allocators to some speed which is proportional to the speed at which the IO
systems can retire writes - view it as a variable-speed polling operation,
in which the polling frequency goes up when the IO system gets faster.
This patch changes that philosophy fundamentally. That's worth more than a
2-line changelog.
Also, there might be situations in which kswapd gets stuck in some dark
corner. Perhaps the process which is waiting in the page allocator holds
filesystem locks which kswapd is blocked on. Or kswapd might be blocked on
a particular request queue, or a dead NFS server or something. The timeout
will save us, but things will be slow.
There could be other problems too, dunno - this stuff is tricky. Why are
you changing it, what problems are being solved, etc?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-04-05 22:57 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 [this message]
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
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=20070405155743.91380f00.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