Re: OOM killer kicks in after minutes or never
On Thu, Dec 24, 2015 at 07:27:14AM +0100, Vlastimil Babka wrote: > +CC so this doesn't get lost > > On 21.12.2015 13:35, Marcin Szewczyk wrote: > > 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. Hi, I thought that due to high throughput of the linux-kernel mailing list my email will not get a reply if it didn't happen in a day so I allowed myself to write another email to linux-mm as well as it was suggested to me on #debian-kernel. The email is here: Subject: Exhausting memory makes the system unresponsive but doesn't invoke OOM killer Message-ID: <20151223143109.GC3519@orkisz> http://marc.info/?t=14508811602=1=2 I have also updated the description in the repository: https://github.com/wodny/crasher Contrary to my original suspicion the OOM killer doesn't need much time to clean up, it just isn't invoked. Johannes Weiner explained the probable cause to me in a response in the linux-mm thread. -- Marcin Szewczyk http://wodny.org mailto:marcin.szewc...@wodny.borg <- remove b / usuń b xmpp:wo...@ubuntu.pl xmpp:wo...@jabster.pl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOM killer kicks in after minutes or never
On Thu, Dec 24, 2015 at 07:27:14AM +0100, Vlastimil Babka wrote: > +CC so this doesn't get lost > > On 21.12.2015 13:35, Marcin Szewczyk wrote: > > 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. Hi, I thought that due to high throughput of the linux-kernel mailing list my email will not get a reply if it didn't happen in a day so I allowed myself to write another email to linux-mm as well as it was suggested to me on #debian-kernel. The email is here: Subject: Exhausting memory makes the system unresponsive but doesn't invoke OOM killer Message-ID: <20151223143109.GC3519@orkisz> http://marc.info/?t=14508811602=1=2 I have also updated the description in the repository: https://github.com/wodny/crasher Contrary to my original suspicion the OOM killer doesn't need much time to clean up, it just isn't invoked. Johannes Weiner explained the probable cause to me in a response in the linux-mm thread. -- Marcin Szewczyk http://wodny.org mailto:marcin.szewc...@wodny.borg <- remove b / usuń b xmpp:wo...@ubuntu.pl xmpp:wo...@jabster.pl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOM killer kicks in after minutes or never
+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) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOM killer kicks in after minutes or never
+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) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOM killer kicks in after minutes or never
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) -- Marcin Szewczyk http://wodny.org mailto:marcin.szewc...@wodny.borg <- remove b / usuń b xmpp:wo...@ubuntu.pl xmpp:wo...@jabster.pl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOM killer kicks in after minutes or never
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.szewc...@wodny.borg <- remove b / usuń b xmpp:wo...@ubuntu.pl xmpp:wo...@jabster.pl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOM killer kicks in after minutes or never
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) -- Marcin Szewczyk http://wodny.org mailto:marcin.szewc...@wodny.borg <- remove b / usuń b xmpp:wo...@ubuntu.pl xmpp:wo...@jabster.pl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOM killer kicks in after minutes or never
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.szewc...@wodny.borg <- remove b / usuń b xmpp:wo...@ubuntu.pl xmpp:wo...@jabster.pl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/