From: Mike Galbraith <mikeg@weiden.de>
To: Roger Larsson <roger.larsson@norran.net>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: 2.4.0-test9-pre4: __alloc_pages(...) try_again:
Date: Fri, 22 Sep 2000 08:20:25 +0200 (CEST) [thread overview]
Message-ID: <Pine.Linu.4.10.10009220754250.1064-100000@mikeg.weiden.de> (raw)
In-Reply-To: <39CA50B0.77A2CD84@norran.net>
On Thu, 21 Sep 2000, Roger Larsson wrote:
> Mike Galbraith wrote:
> >
> > On Wed, 20 Sep 2000, Roger Larsson wrote:
> >
> > > Hi,
> > >
> > >
> > > Trying to find out why test9-pre4 freezes with mmap002
> > > I added a counter for try_again loops.
> > >
> > > ... __alloc_pages(...)
> > >
> > > int direct_reclaim = 0;
> > > unsigned int gfp_mask = zonelist->gfp_mask;
> > > struct page * page = NULL;
> > > + int try_again_loops = 0;
> > >
> > > - - -
> > >
> > > + printk("VM: sync kswapd (direct_reclaim: %d) try_again #
> > > %d\n",
> > > + direct_reclaim, ++try_again_loops);
> > > wakeup_kswapd(1);
> > > goto try_again;
> > >
> > >
> > > Result was surprising:
> > > direct_reclaim was 1.
> > > try_again_loops did never stop increasing (note: it is not static,
> > > and should restart from zero after each success)
> > >
> > > Why does this happen?
> > > a) kswapd did not succeed in freeing a suitable page?
> > > b) __alloc_pages did not succeed in grabbing the page?
> >
> > Hi Roger,
> >
> > A trace of locked up box shows endless repetitions of kswapd aparantly
> > failing to free anything. What I don't see in the trace snippet below
> > is reclaim_page(). I wonder if this test in __alloc_pages_limit()
> > should include an || direct_reclaim.
>
> When I have run into this problem I have had no inactive_clean pages =>
> reclaim_page() should not work... :-(
> That is your situation too...
(Yup, after further reading I quickly ceased wondering about that;)
Much more interesting (i hope) is that refill_inactive() _is_ present
2923 times, we're oom as heck, and neither shm_swap() nor swap_out()
is ever reached in 1048533 lines of trace. The only way I can see that
this can happen is if refill_inactive_scan() eats all count.
:-) I'm currently wo^Handering what count is and if I shouldn't try
checking nr_inactive_clean_pages() before exiting the loop.
-Mike
--
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.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-09-22 6:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-09-20 20:23 Roger Larsson
2000-09-21 5:21 ` Mike Galbraith
2000-09-21 18:17 ` Roger Larsson
2000-09-22 6:20 ` Mike Galbraith [this message]
2000-09-22 8:49 ` Rik van Riel
2000-09-22 16:51 ` Mike Galbraith
2000-09-23 11:28 ` 2.4.0-test9-pre6: __alloc_pages(...) datapoint Mike Galbraith
2000-09-21 16:26 ` 2.4.0-test9-pre4: __alloc_pages(...) try_again: Rik van Riel
2000-09-21 17:58 ` Roger Larsson
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=Pine.Linu.4.10.10009220754250.1064-100000@mikeg.weiden.de \
--to=mikeg@weiden.de \
--cc=linux-mm@kvack.org \
--cc=roger.larsson@norran.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox