From: Nai Xia <nai.xia@gmail.com>
To: "Paweł Sikora" <pluto@agmk.net>
Cc: Hugh Dickins <hughd@google.com>,
arekm@pld-linux.org,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-mm@kvack.org, Mel Gorman <mgorman@suse.de>,
jpiszcz@lucidpixels.com, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110
Date: Sat, 22 Oct 2011 14:21:23 +0800 [thread overview]
Message-ID: <201110221421.23181.nai.xia@gmail.com> (raw)
In-Reply-To: <201110212336.47267.pluto@agmk.net>
On Saturday 22 October 2011 05:36:46 Paweł Sikora wrote:
> On Friday 21 of October 2011 11:07:56 Nai Xia wrote:
> > On Fri, Oct 21, 2011 at 4:07 PM, Pawel Sikora <pluto@agmk.net> wrote:
> > > On Friday 21 of October 2011 14:22:37 Nai Xia wrote:
> > >
> > >> And as a side note. Since I notice that Pawel's workload may include OOM,
> > >
> > > my last tests on patched (3.0.4 + migrate.c fix + vserver) kernel produce full cpu load
> > > on dual 8-cores opterons like on this htop screenshot -> http://pluto.agmk.net/kernel/screen1.png
> > > afaics all userspace applications usualy don't use more than half of physical memory
> > > and so called "cache" on htop bar doesn't reach the 100%.
> >
> > OK，did you logged any OOM killing if there was some memory usage burst?
> > But, well my above OOM reasoning is a direct short cut to imagined
> > root cause of "adjacent VMAs which
> > should have been merged but in fact not merged" case.
> > Maybe there are other cases that can lead to this or maybe it's
> > totally another bug....
>
> i don't see any OOM killing with my conservative settings
> (vm.overcommit_memory=2, vm.overcommit_ratio=100).
OK, that does not matter now. Andrea showed us a simpler way to goto
this bug.
>
> > But still I think if my reasoning is good, similar bad things will
> > happen again some time in the future,
> > even if it was not your case here...
> >
> > >
> > > the patched kernel with disabled CONFIG_TRANSPARENT_HUGEPAGE (new thing in 2.6.38)
> > > died at night, so now i'm going to disable also CONFIG_COMPACTION/MIGRATION in next
> > > steps and stress this machine again...
> >
> > OK, it's smart to narrow down the range first....
>
> disabling hugepage/compacting didn't help but disabling hugepage/compacting/migration keeps
> opterons stable for ~9h so far. userspace uses ~40GB (from 64) ram, caches reach 100% on htop bar,
> average load ~16. i wonder if it survive weekend...
>
Maybe you should give another shot of Andrea's latest anon_vma_order_tail() patch. :)
WARNING: multiple messages have this Message-ID (diff)
From: Nai Xia <nai.xia@gmail.com>
To: "Paweł Sikora" <pluto@agmk.net>
Cc: Hugh Dickins <hughd@google.com>,
arekm@pld-linux.org,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-mm@kvack.org, Mel Gorman <mgorman@suse.de>,
jpiszcz@lucidpixels.com, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110
Date: Sat, 22 Oct 2011 14:21:23 +0800 [thread overview]
Message-ID: <201110221421.23181.nai.xia@gmail.com> (raw)
In-Reply-To: <201110212336.47267.pluto@agmk.net>
On Saturday 22 October 2011 05:36:46 Paweł Sikora wrote:
> On Friday 21 of October 2011 11:07:56 Nai Xia wrote:
> > On Fri, Oct 21, 2011 at 4:07 PM, Pawel Sikora <pluto@agmk.net> wrote:
> > > On Friday 21 of October 2011 14:22:37 Nai Xia wrote:
> > >
> > >> And as a side note. Since I notice that Pawel's workload may include OOM,
> > >
> > > my last tests on patched (3.0.4 + migrate.c fix + vserver) kernel produce full cpu load
> > > on dual 8-cores opterons like on this htop screenshot -> http://pluto.agmk.net/kernel/screen1.png
> > > afaics all userspace applications usualy don't use more than half of physical memory
> > > and so called "cache" on htop bar doesn't reach the 100%.
> >
> > OK，did you logged any OOM killing if there was some memory usage burst?
> > But, well my above OOM reasoning is a direct short cut to imagined
> > root cause of "adjacent VMAs which
> > should have been merged but in fact not merged" case.
> > Maybe there are other cases that can lead to this or maybe it's
> > totally another bug....
>
> i don't see any OOM killing with my conservative settings
> (vm.overcommit_memory=2, vm.overcommit_ratio=100).
OK, that does not matter now. Andrea showed us a simpler way to goto
this bug.
>
> > But still I think if my reasoning is good, similar bad things will
> > happen again some time in the future,
> > even if it was not your case here...
> >
> > >
> > > the patched kernel with disabled CONFIG_TRANSPARENT_HUGEPAGE (new thing in 2.6.38)
> > > died at night, so now i'm going to disable also CONFIG_COMPACTION/MIGRATION in next
> > > steps and stress this machine again...
> >
> > OK, it's smart to narrow down the range first....
>
> disabling hugepage/compacting didn't help but disabling hugepage/compacting/migration keeps
> opterons stable for ~9h so far. userspace uses ~40GB (from 64) ram, caches reach 100% on htop bar,
> average load ~16. i wonder if it survive weekend...
>
Maybe you should give another shot of Andrea's latest anon_vma_order_tail() patch. :)
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-10-22 6:21 UTC|newest]
Thread overview: 143+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-12 18:12 kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110 Paweł Sikora
2011-10-13 23:16 ` Hugh Dickins
2011-10-13 23:30 ` Hugh Dickins
2011-10-13 23:30 ` Hugh Dickins
2011-10-16 16:11 ` Christoph Hellwig
2011-10-16 16:11 ` Christoph Hellwig
2011-10-16 23:54 ` Andrea Arcangeli
2011-10-16 23:54 ` Andrea Arcangeli
2011-10-17 18:51 ` Hugh Dickins
2011-10-17 18:51 ` Hugh Dickins
2011-10-17 22:05 ` Andrea Arcangeli
2011-10-17 22:05 ` Andrea Arcangeli
2011-10-19 7:43 ` Mel Gorman
2011-10-19 7:43 ` Mel Gorman
2011-10-19 13:39 ` Linus Torvalds
2011-10-19 13:39 ` Linus Torvalds
2011-10-19 19:42 ` Hugh Dickins
2011-10-19 19:42 ` Hugh Dickins
2011-10-20 6:30 ` Paweł Sikora
2011-10-20 6:30 ` Paweł Sikora
2011-10-20 6:51 ` Linus Torvalds
2011-10-20 6:51 ` Linus Torvalds
2011-10-21 6:54 ` Nai Xia
2011-10-21 6:54 ` Nai Xia
2011-10-21 7:35 ` Pawel Sikora
2011-10-21 7:35 ` Pawel Sikora
2011-10-20 12:51 ` Nai Xia
2011-10-20 12:51 ` Nai Xia
2011-10-20 18:36 ` Hugh Dickins
2011-10-21 6:22 ` Nai Xia
2011-10-21 6:22 ` Nai Xia
2011-10-21 8:07 ` Pawel Sikora
2011-10-21 8:07 ` Pawel Sikora
2011-10-21 9:07 ` Nai Xia
2011-10-21 9:07 ` Nai Xia
2011-10-21 21:36 ` Paweł Sikora
2011-10-21 21:36 ` Paweł Sikora
2011-10-22 6:21 ` Nai Xia [this message]
2011-10-22 6:21 ` Nai Xia
2011-10-22 16:42 ` Paweł Sikora
2011-10-22 16:42 ` Paweł Sikora
[not found] ` <CAPQyPG5HJKTo8AEy_khdJeciTgtNQepK6XLcpzvPF8PYS0V-Lw@mail.gmail.com>
2011-10-25 7:33 ` Pawel Sikora
2011-10-20 9:11 ` Nai Xia
2011-10-20 9:11 ` Nai Xia
2011-10-21 15:56 ` Mel Gorman
2011-10-21 15:56 ` Mel Gorman
2011-10-21 17:21 ` Nai Xia
2011-10-21 17:21 ` Nai Xia
2011-10-21 17:41 ` Andrea Arcangeli
2011-10-21 17:41 ` Andrea Arcangeli
2011-10-21 22:50 ` Andrea Arcangeli
2011-10-21 22:50 ` Andrea Arcangeli
2011-10-22 5:52 ` Nai Xia
2011-10-22 5:52 ` Nai Xia
2011-10-31 17:14 ` Andrea Arcangeli
2011-10-31 17:14 ` Andrea Arcangeli
2011-10-31 17:27 ` [PATCH] mremap: enforce rmap src/dst vma ordering in case of vma_merge succeeding in copy_vma Andrea Arcangeli
2011-10-31 17:27 ` Andrea Arcangeli
2011-11-01 12:07 ` Mel Gorman
2011-11-01 12:07 ` Mel Gorman
2011-11-01 14:35 ` Nai Xia
2011-11-01 14:35 ` Nai Xia
2011-11-04 7:31 ` Hugh Dickins
2011-11-04 7:31 ` Hugh Dickins
2011-11-04 14:34 ` Nai Xia
2011-11-04 14:34 ` Nai Xia
2011-11-04 15:59 ` Pawel Sikora
2011-11-04 15:59 ` Pawel Sikora
2011-11-05 2:21 ` Nai Xia
2011-11-05 2:21 ` Nai Xia
2011-11-04 19:16 ` Hugh Dickins
2011-11-04 20:54 ` Andrea Arcangeli
2011-11-04 20:54 ` Andrea Arcangeli
2011-11-05 0:09 ` Nai Xia
2011-11-05 0:09 ` Nai Xia
2011-11-05 2:21 ` Hugh Dickins
2011-11-05 3:07 ` Andrea Arcangeli
2011-11-05 3:07 ` Andrea Arcangeli
2011-11-05 17:06 ` Andrea Arcangeli
2011-11-05 17:06 ` Andrea Arcangeli
2011-12-08 3:24 ` David Rientjes
2011-12-08 3:24 ` David Rientjes
2011-12-08 12:42 ` Andrea Arcangeli
2011-12-08 12:42 ` Andrea Arcangeli
2011-12-09 0:08 ` Andrew Morton
2011-12-09 0:08 ` Andrew Morton
2011-12-09 1:55 ` Andrea Arcangeli
2011-12-09 1:55 ` Andrea Arcangeli
2011-11-04 23:56 ` Andrea Arcangeli
2011-11-04 23:56 ` Andrea Arcangeli
2011-11-05 0:21 ` Nai Xia
2011-11-05 0:21 ` Nai Xia
2011-11-05 0:59 ` Nai Xia
2011-11-05 0:59 ` Nai Xia
2011-11-05 1:33 ` Andrea Arcangeli
2011-11-05 1:33 ` Andrea Arcangeli
2011-11-05 2:00 ` Nai Xia
2011-11-05 2:00 ` Nai Xia
2011-11-07 13:14 ` Mel Gorman
2011-11-07 13:14 ` Mel Gorman
2011-11-07 15:42 ` Andrea Arcangeli
2011-11-07 15:42 ` Andrea Arcangeli
2011-11-07 16:28 ` Mel Gorman
2011-11-07 16:28 ` Mel Gorman
2011-11-09 1:25 ` Andrea Arcangeli
2011-11-09 1:25 ` Andrea Arcangeli
2011-11-11 9:14 ` Nai Xia
2011-11-11 9:14 ` Nai Xia
2011-11-16 14:00 ` Andrea Arcangeli
2011-11-16 14:00 ` Andrea Arcangeli
2011-11-17 0:16 ` Hugh Dickins
2011-11-17 0:16 ` Hugh Dickins
2011-11-17 2:49 ` Nai Xia
2011-11-17 2:49 ` Nai Xia
2011-11-17 6:21 ` Nai Xia
2011-11-17 6:21 ` Nai Xia
2011-11-17 18:42 ` Andrea Arcangeli
2011-11-17 18:42 ` Andrea Arcangeli
2011-11-18 1:42 ` Nai Xia
2011-11-18 1:42 ` Nai Xia
2011-11-18 2:17 ` Andrea Arcangeli
2011-11-18 2:17 ` Andrea Arcangeli
2011-11-19 9:15 ` Nai Xia
2011-11-19 9:15 ` Nai Xia
2011-10-22 5:07 ` kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110 Nai Xia
2011-10-22 5:07 ` Nai Xia
2011-10-31 16:34 ` Andrea Arcangeli
2011-10-31 16:34 ` Andrea Arcangeli
2011-10-16 22:37 ` Linus Torvalds
2011-10-16 22:37 ` Linus Torvalds
2011-10-17 3:02 ` Hugh Dickins
2011-10-17 3:02 ` Hugh Dickins
2011-10-17 3:09 ` Linus Torvalds
2011-10-17 3:09 ` Linus Torvalds
2011-10-18 19:17 ` Paweł Sikora
2011-10-19 7:30 ` Mel Gorman
2011-10-21 12:44 ` Mel Gorman
-- strict thread matches above, loose matches on Subject: below --
2011-08-15 16:43 Justin Piszcz
2011-08-15 18:18 ` Hugh Dickins
2011-08-15 19:02 ` Justin Piszcz
2011-08-15 19:53 ` Hugh Dickins
2011-08-21 17:59 ` Maciej Rutecki
2011-08-21 18:49 ` Justin Piszcz
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=201110221421.23181.nai.xia@gmail.com \
--to=nai.xia@gmail.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arekm@pld-linux.org \
--cc=hughd@google.com \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=pluto@agmk.net \
--cc=torvalds@linux-foundation.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 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.