From: David Rientjes <rientjes@google.com>
To: PINTU KUMAR <pintu.k@samsung.com>
Cc: akpm@linux-foundation.org, minchan@kernel.org, dave@stgolabs.net,
mhocko@suse.cz, koct9i@gmail.com, hannes@cmpxchg.org,
penguin-kernel@i-love.sakura.ne.jp, bywxiaobai@163.com,
mgorman@suse.de, vbabka@suse.cz, js1304@gmail.com,
kirill.shutemov@linux.intel.com, alexander.h.duyck@redhat.com,
sasha.levin@oracle.com, cl@linux.com, fengguang.wu@intel.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
cpgs@samsung.com, pintu_agarwal@yahoo.com, pintu.ping@gmail.com,
vishnu.ps@samsung.com, rohit.kr@samsung.com,
c.rajkumar@samsung.com
Subject: RE: [RESEND PATCH 1/1] mm: vmstat: Add OOM victims count in vmstat counter
Date: Wed, 14 Oct 2015 15:04:57 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.10.1510141501470.32680@chino.kir.corp.google.com> (raw)
In-Reply-To: <081301d10686$370d2e10$a5278a30$@samsung.com>
On Wed, 14 Oct 2015, PINTU KUMAR wrote:
> For me it was very helpful during sluggish and long duration ageing tests.
> With this, I don't have to look into the logs manually.
> I just monitor this count in a script.
> The moment I get nr_oom_victims > 1, I know that kernel OOM would have happened
> and I need to take the log dump.
> So, then I do: dmesg >> oom_logs.txt
> Or, even stop the tests for further tuning.
>
I think eventfd(2) was created for that purpose, to avoid the constant
polling that you would have to do to check nr_oom_victims and then take a
snapshot.
> > I disagree with this one, because we can encounter oom kills due to
> > fragmentation rather than low memory conditions for high-order allocations.
> > The amount of free memory may be substantially higher than all zone
> > watermarks.
> >
> AFAIK, kernel oom happens only for lower-order (PAGE_ALLOC_COSTLY_ORDER).
> For higher-order we get page allocation failure.
>
Order-3 is included. I've seen machines with _gigabytes_ of free memory
in ZONE_NORMAL on a node and have an order-3 page allocation failure that
called the oom killer.
> > We've long had a desire to have a better oom reporting mechanism rather than
> > just the kernel log. It seems like you're feeling the same pain. I think it
> would be
> > better to have an eventfd notifier for system oom conditions so we can track
> > kernel oom kills (and conditions) in userspace. I have a patch for that, and
> it
> > works quite well when userspace is mlocked with a buffer in memory.
> >
> Ok, this would be interesting.
> Can you point me to the patches?
> I will quickly check if it is useful for us.
>
https://lwn.net/Articles/589404. It's invasive and isn't upstream. I
would like to restructure that patchset to avoid the memcg trickery and
allow for a root-only eventfd(2) notification through procfs on system
oom.
--
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:[~2015-10-14 22:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-01 10:48 [PATCH 1/1] mm: vmstat: Add OOM kill " Pintu Kumar
2015-10-01 13:29 ` Anshuman Khandual
2015-10-05 6:19 ` PINTU KUMAR
2015-10-01 13:38 ` Michal Hocko
2015-10-05 6:12 ` PINTU KUMAR
2015-10-05 12:22 ` Michal Hocko
2015-10-06 6:59 ` PINTU KUMAR
2015-10-06 15:41 ` Michal Hocko
2015-10-07 14:48 ` PINTU KUMAR
2015-10-08 14:18 ` Michal Hocko
2015-10-08 16:06 ` PINTU KUMAR
2015-10-08 16:30 ` Michal Hocko
2015-10-09 12:59 ` PINTU KUMAR
2015-10-12 13:33 ` [PATCH 1/1] mm: vmstat: Add OOM victims " Pintu Kumar
2015-10-12 14:28 ` [RESEND PATCH " Pintu Kumar
2015-10-14 3:05 ` David Rientjes
2015-10-14 13:41 ` PINTU KUMAR
2015-10-14 22:04 ` David Rientjes [this message]
2015-10-15 14:35 ` PINTU KUMAR
2015-10-12 14:44 ` [PATCH " PINTU KUMAR
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=alpine.DEB.2.10.1510141501470.32680@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@redhat.com \
--cc=bywxiaobai@163.com \
--cc=c.rajkumar@samsung.com \
--cc=cl@linux.com \
--cc=cpgs@samsung.com \
--cc=dave@stgolabs.net \
--cc=fengguang.wu@intel.com \
--cc=hannes@cmpxchg.org \
--cc=js1304@gmail.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=koct9i@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=minchan@kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=pintu.k@samsung.com \
--cc=pintu.ping@gmail.com \
--cc=pintu_agarwal@yahoo.com \
--cc=rohit.kr@samsung.com \
--cc=sasha.levin@oracle.com \
--cc=vbabka@suse.cz \
--cc=vishnu.ps@samsung.com \
/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