From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753266AbbJOOfa (ORCPT ); Thu, 15 Oct 2015 10:35:30 -0400 Received: from mailout3.samsung.com ([203.254.224.33]:38754 "EHLO mailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751752AbbJOOf2 (ORCPT ); Thu, 15 Oct 2015 10:35:28 -0400 X-AuditID: cbfee690-f794e6d0000014de-07-561fb9ad8207 From: PINTU KUMAR To: "'David Rientjes'" 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 References: <1444656800-29915-1-git-send-email-pintu.k@samsung.com> <1444660139-30125-1-git-send-email-pintu.k@samsung.com> <081301d10686$370d2e10$a5278a30$@samsung.com> In-reply-to: Subject: RE: [RESEND PATCH 1/1] mm: vmstat: Add OOM victims count in vmstat counter Date: Thu, 15 Oct 2015 20:05:17 +0530 Message-id: <002101d10756$dcae7e20$960b7a60$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQJMXYG34mF3dXtZVCEjGRrPxnXARgFDhPPaANqCrXgC4xGOAQI3jFYMnTwoowA= Content-language: en-us X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURzGO+91joy3eTtJZgkSClmzWSeUKOrDSxctLD8YtKa+meStzUUX IsNUWjq8zC7zwlKRNSfL2QctE11qRiWKRVprzi4zyzmK8rJEc75+8Nvv8Pz/z/Nw+Atw0RAZ KEjLzOHkmbL0EEpIGH0lV7Y1tQUn7Ogpi0ZVJiOF5hfuEkhdtRXd1pRj6P30JEATljDUOGIE yDVuwlGj+Si6/6yaRCPjVQR6eMtOoqEnVRSyGRdJVD7lAOhH3gyJGv66aFR5c4pE7yfuEGja +ZFGBfXNGBrPyydQXfdHHFXeUAOkUX8C+zawdXoNyT6fdOFsm/YTzerMSratyYCxde0TGGs2 3KJY8+8ymu27949gv769i7E1L4+zv759IFhXxzuKVT82ALai8jr7WtdNH/NJFMakcOlpFzn5 9r1nhOd6SubJ7PqNlyzuYjwXOP1VQCCAjAS2DEpVwGsJ/eGAzUSpgFAgYvQA2js0gBcksKvi A8YLWgDvfKldeTgBHPjVQHmcKGYr7O309iz4MuFwdK5ueRln9AS0Dsv4+WYMfsn/QXkEL+YI bBmpoD3sw5yENqt1mQkmFOq6HbiHvZk90PFVT/O8Hs6W2wjeNBya2l5gPAfDFqMT55tuhq1v fgK+RCx0j5hWZgJgmX2M9pSAzFMvmPe5ZCWMgdPlFoL/iiBo7lzx2QC79MNECYDaVdHaVdHa VdHaVRE6QBiAH5ednK1ISpVLIhSyDIUyMzUiOSvDDJZu7dWCo6QV2DqjLYARgJC13n32TQki UnZRcTnDAqKWGpXigX7JWUvnmZkjFe/cFYmiJFE7I3fv2RUS4P0zcC5exKTKcrjzHJfNyaVy ZTqnsABM4BWYC6rVqn6xsqjmQcw6v/3WUZoyxgVLi/+UwoeL7YNujbk1Pk4k7VcdlF9TtDa4 hoPCdLtTDsD9WYm1/h19WuXM93cvX/Ta1N8jcmP1pw+P2k1JV6+cmA1PTX5UoKGt0QGLWy4c CpvOEJ4NLRV/niusds8UnBJO/i0akzgKz/oFrQkhFOdk4nBcrpD9B3ZaNghmAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIJsWRmVeSWpSXmKPExsVy+t9jQd21O+XDDOa/07GYs34Nm8Wff9NZ LPrmqFt0T5nMZHH92xtGi5eHNC1W31zDaPH++Xpmi9WbfC1m7p3LanHz+RwWi5WdD1gtLu+a w2Zxb81/VovJ754xWrxq/s5qsezre3aL2S3vWC2uv5zGYvHt7W12i7YlG5ksnje3slgsPnKb 2WJ2Yx+jxZS+u4wOkh6LV0xh9Tj85j2zx85Zd9k9Fmwq9di5dhWTx+I9L5k8Nq3qZPPY9GkS u8eJGb9ZPJ5cmc7kMe9koMfHp7dYPN7vu8rm0bdlFaPH1Nn1HmcWHGEPEI5qYLTJSE1MSS1S SM1Lzk/JzEu3VfIOjneONzUzMNQ1tLQwV1LIS8xNtVVy8QnQdcvMAYaJkkJZYk4pUCggsbhY Sd8O04TQEDddC5jGCF3fkCC4HiMDNJCwhjHj6IQ/rAVLZCoO/eplbmB8K9bFyMkhIWAicXDq LSYIW0ziwr31bF2MXBxCArMYJaY9XsQE4bxllLjwcRlQhoODTUBd4tgBXpAGEQEtifs/FzOC 2MwCK1gk7txIhKjfyCTxuPUVG0iCU8BHYvPNqewgtrBAqMS9O3fAbBYBVYkFR54xg9i8ApYS z56sYIewBSV+TL7HAjFUS2L9zuNMELa8xOY1b5khLlWQ2HH2NSPEEX4Sv26uh6oRl5j04CH7 BEahWUhGzUIyahaSUbOQtCxgZFnFKJFakFxQnJSea5SXWq5XnJhbXJqXrpecn7uJEZw8n0nv YDy8y/0QowAHoxIP74kHcmFCrIllxZW5hxglOJiVRHj7quTDhHhTEiurUovy44tKc1KLDzGa Aj07kVlKNDkfmNjzSuINjU3MTY1NLU0sTMwslcR5bxxiCBMSSE8sSc1OTS1ILYLpY+LglGpg dJa1ztP+8eVuatSlxV+0GMvib9zhf2ZavNO4aIftIzuh9+k68Wdf1z2Z1z5zw/3Xi6OY/2bt do09K7BLQ8j3JpPN+Q9PFrku6RQ1FNvNWOgvs9FGX7PXaH+BqECAC0OfpMD/e5l+VVcmeF6U to87l7SRU1tsxd/k/w+2SZ9190hhm1W9xMpIiaU4I9FQi7moOBEAgvSnBrQDAAA= DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > -----Original Message----- > From: David Rientjes [mailto:rientjes@google.com] > Sent: Thursday, October 15, 2015 3:35 AM > To: PINTU KUMAR > 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 > > 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. > Yes, if PAGE_ALLOC_COSTLY_ORDER is defined as 3, then order-3 will be included for OOM. But that's fine. We are just interested to know if system entered oom state. That's the reason, earlier I added even _oom_stall_ to know if system ever entered oom but resulted into page allocation failure instead of oom killing. > > > 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. I am interested only in global oom case and not memcg. We have memcg enabled but I think even memcg_oom will finally invoke _oom_kill_process_. So, I am interested in a patchset that can trigger notifications from oom_kill_process, as soon as any victim is killed. Sorry, from your patchset, I could not actually local the system_oom notification patch. If you have similar patchset please point me to it. It will be really helpful. Thank you!