From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932882AbbLXG1I (ORCPT ); Thu, 24 Dec 2015 01:27:08 -0500 Received: from mx2.suse.de ([195.135.220.15]:58270 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932650AbbLXG1G (ORCPT ); Thu, 24 Dec 2015 01:27:06 -0500 Subject: Re: OOM killer kicks in after minutes or never To: Marcin Szewczyk , linux-kernel@vger.kernel.org, Linux-MM References: <20151221123557.GE3060@orkisz> Cc: Michal Hocko , Tetsuo Handa , David Rientjes From: Vlastimil Babka Message-ID: <567B9042.9010105@suse.cz> Date: Thu, 24 Dec 2015 07:27:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151221123557.GE3060@orkisz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +CC so this doesn't get lost On 21.12.2015 13:35, Marcin Szewczyk wrote: > 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? > > > (Sorry if a duplicate appears) >