Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751423AbbLUMMj (ORCPT ); Mon, 21 Dec 2015 07:12:39 -0500 Received: from n26.netmark.pl ([94.124.9.61]:52206 "EHLO n26.netmark.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751081AbbLUMMh (ORCPT ); Mon, 21 Dec 2015 07:12:37 -0500 X-Greylist: delayed 3508 seconds by postgrey-1.27 at vger.kernel.org; Mon, 21 Dec 2015 07:12:37 EST Date: Mon, 21 Dec 2015 12:14:00 +0100 From: Marcin Szewczyk To: linux-kernel@vger.kernel.org Subject: OOM killer kicks in after minutes or never Message-ID: <20151221111400.GC3060@orkisz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.23 (2014-03-12) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - n26.netmark.pl X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - wodny.org X-Get-Message-Sender-Via: n26.netmark.pl: authenticated_id: wodny/from_h X-Authenticated-Sender: n26.netmark.pl: Marcin.Szewczyk@wodny.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2175 Lines: 51 Hi, In 2010 I noticed that viewing many GIFs in a row using gpicview renders my Linux unresponsive. There is very little I can do in such a situation. Rarely after some minutes the OOM killer kicks in and saves the day. Nevertheless, usually I end up using Alt+SysRq+B. This is the second computer I can observe this problem on. First was Asus EeePC 1000 with Atom N270 and now I have Lenovo S210 with Celeron 1037U. What happens is gpicview exhausting whole available memory in such a pattern that userspace becomes unresponsive. I cannot switch to another terminal either. I have written a tool that allocates memory in a very similar way using GDK -- https://github.com/wodny/crasher. I have also uploaded some logs to the repository -- top, iostat (showing a lot of reads during an episode), dmesg. I suppose the OS starts to oscillate between freeing memory, cleaning caches and buffers, and loading some new data (see iostat logs). Currently I am using Debian Jessie with the following kernel: 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09) x86_64 GNU/Linux I can observe the most impressive effects on my physical machine (logs/ph-*). On a VM (logs/vm-*) usually the OOM killer kills the process after a short time (5-120 seconds). Possible factors differentiating cases of recovering in seconds from recoveries after minutes (or never): - another memory-consuming process running (e.g. Firefox), - physical machine or a VM (see dmesg logs), - chipset and associated kernel functions (see dmesg logs). Things that seem irrelevant (after testing): - running the application in Xorg or a TTY, - LUKS encryption of the root filesystem, - vm.oom_kill_allocating_task setting. What can I do to diagnose the problem further? -- Marcin Szewczyk http://wodny.org mailto:Marcin.Szewczyk@wodny.borg <- remove b / usuĊ„ b xmpp:wodny@ubuntu.pl xmpp:wodny@jabster.pl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/