From: Luigi Semenzato <semenzato@google.com>
To: Minchan Kim <minchan@kernel.org>
Cc: linux-mm@kvack.org, Dan Magenheimer <dan.magenheimer@oracle.com>,
Bryan Freed <bfreed@google.com>
Subject: Re: another allocation livelock with zram
Date: Mon, 26 Nov 2012 17:00:26 -0800 [thread overview]
Message-ID: <CAA25o9Rbt17E9vNP=J0rkfGnu=YQPhZpeUA+nnaHNRWht0M05w@mail.gmail.com> (raw)
In-Reply-To: <20121123054446.GB13626@bbox>
Still no measurable progress on this one, but some new information.
To recapitulate:
--- vanilla 3.4 kernel + hacky min_filelist_kbytes patch + Minchan's
patch below:
>> > --- a/mm/vmscan.c
>> > +++ b/mm/vmscan.c
>> > @@ -2101,7 +2101,7 @@ static bool all_unreclaimable(struct zonelist *zonelist,
>> > continue;
>> > if (!cpuset_zone_allowed_hardwall(zone, GFP_KERNEL))
>> > continue;
>> > - if (!zone->all_unreclaimable)
>> > + if (zone->pages_scanned < zone_reclaimable_pages(zone) * 6)
>> > return false;
>> > }
--- no longer running the Chrome browser; instead, running this
synthetic load: several instances of a process that allocates 200MB,
then touches some subset of its pages in an endless loop. The
process's data segment compresses well (10:1).
--- running the load on two similar systems: one ARM-based, the other
x86-based. Both systems run the same kernel and the same image
(different but equivalent configurations). Both have 2 GB RAM.
On the x86 system, the mm behaves as expected. All 3 Gb of the zram
device are consumed before OOM-kills happen.
On the ARM system, OOM kills start happening when there are still
about 2.1 GB of swap available. Because the compression ratio is so
good, the zram disk is only using 100 to 150 MB.
The systems are pretty similar. The x86 device has a rotating disk,
vs. SSD on the ARM device. This could affect the speed of paging in
code, but the program is very small so I don't think that's a factor.
There are no messages from zram in the log.
It could be either an ARM bug, or maybe the bug is on both systems,
and the performance behavior on ARM is different enough to expose it.
I will continue trying to figure out why kswapd isn't more proactive on ARM.
Thanks!
Luigi
--
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:[~2012-11-27 1:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-20 23:46 Luigi Semenzato
2012-11-21 1:27 ` Minchan Kim
2012-11-21 1:47 ` Luigi Semenzato
2012-11-21 13:59 ` Minchan Kim
2012-11-21 18:21 ` Luigi Semenzato
2012-11-23 5:44 ` Minchan Kim
2012-11-27 1:00 ` Luigi Semenzato [this message]
2012-11-28 6:12 ` Minchan Kim
2013-02-17 3:33 ` Jaegeuk Hanse
2013-02-17 4:55 ` Luigi Semenzato
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='CAA25o9Rbt17E9vNP=J0rkfGnu=YQPhZpeUA+nnaHNRWht0M05w@mail.gmail.com' \
--to=semenzato@google.com \
--cc=bfreed@google.com \
--cc=dan.magenheimer@oracle.com \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
/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