All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Andrey Korolyov <andrey@xdel.ru>, jesper@krogh.cc
Cc: linux-mm@kvack.org, Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Christian Marie <christian@ponies.io>
Subject: Re: High system load and 3TB of memory.
Date: Wed, 18 Mar 2015 15:15:56 +0100	[thread overview]
Message-ID: <5509889C.2080602@suse.cz> (raw)
In-Reply-To: <CABYiri9BcgNEYD5C4qGf=3q6a=d549Rp9rXD7BAo8NkVDAPOqA@mail.gmail.com>

On 03/14/2015 06:33 PM, Andrey Korolyov wrote:
> 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.

Right, it would be great if you could try it with 3.18+ kernel and 
possibly Joonsoo's patch from
http://marc.info/?l=linux-mm&m=141774145601066


--
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-18 14:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-14 17:05 High system load and 3TB of memory jesper
2015-03-14 17:14 ` Andrey Korolyov
2015-03-14 17:25   ` jesper
2015-03-14 17:33     ` Andrey Korolyov
2015-03-18 14:15       ` Vlastimil Babka [this message]
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=5509889C.2080602@suse.cz \
    --to=vbabka@suse.cz \
    --cc=andrey@xdel.ru \
    --cc=christian@ponies.io \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jesper@krogh.cc \
    --cc=linux-mm@kvack.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.