linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrey Korolyov <andrey@xdel.ru>
To: jesper@krogh.cc
Cc: linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Christian Marie <christian@ponies.io>
Subject: Re: High system load and 3TB of memory.
Date: Sat, 14 Mar 2015 20:33:08 +0300	[thread overview]
Message-ID: <CABYiri9BcgNEYD5C4qGf=3q6a=d549Rp9rXD7BAo8NkVDAPOqA@mail.gmail.com> (raw)
In-Reply-To: <a0dcd8d7307e313474d4d721c76bb5a9.squirrel@shrek.krogh.cc>

On Sat, Mar 14, 2015 at 8:25 PM,  <jesper@krogh.cc> wrote:
>> On Sat, Mar 14, 2015 at 8:05 PM,  <jesper@krogh.cc> wrote:
>>> Hi
>>> I have a 3.13 (ubuntu LTS) server with 3TB of memory and under certain
>>> load
>>> conditions it can spiral off to 80+% system load. Per recommendation on
>>> IRC
>>> yesterday I have captured 2 perf reports (I'm new to perf, so I'm not
>>> sure they tell precisely whats needed.
>>>
>>> Bad situation (high sysload 80%+)
>
>
>> Hi Jesper, please take a look on
>> http://marc.info/?l=linux-mm&m=141605213522925&w=2, there is a long
>> and unfinished discussion as it seems very problematic to make a
>> deterministic reproduction of the bug in our environments. If you can
>> observe same lockups with more ease, it`ll help a lot in the issue
>> pinning and fixing.
>
>
> Hi Andrey.
>
> Yes it looks indeed familiar. I can do a fair amount of testing and our
> normal production load triggers the problem 6-10 times per day and I'm
> willing to garther data to help move forward. What do you suggest is next?
>
> Jesper
>
>

There is a couple of patches suggested by Vlastimil and others through
discussion, not me neither Christian was able to test them properly
due to kind of environment where bug primarily live (production envs
for both of us). The bare test-env reproducer is a big step forward
indeed. Since then bug was reported a couple of times and workarounded
(by setting ridiculously large amount of memory for vm.min_free), the
larger memory room is (given intensive disk i/o which is able to fill
all memory with certain ratio of active/inactive pages I suppose), the
easier it is to catch the issue.

--
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>

  reply	other threads:[~2015-03-14 17:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-14 17:05 jesper
2015-03-14 17:14 ` Andrey Korolyov
2015-03-14 17:25   ` jesper
2015-03-14 17:33     ` Andrey Korolyov [this message]
2015-03-18 14:15       ` Vlastimil Babka
2015-03-18 15:14         ` Jesper Krogh
2015-03-19 12:51           ` Joonsoo Kim

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='CABYiri9BcgNEYD5C4qGf=3q6a=d549Rp9rXD7BAo8NkVDAPOqA@mail.gmail.com' \
    --to=andrey@xdel.ru \
    --cc=christian@ponies.io \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jesper@krogh.cc \
    --cc=linux-mm@kvack.org \
    --cc=vbabka@suse.cz \
    /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