Summary: | Recursive process loops hang (crash) Linux | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Robert Bradbury <robert.bradbury> |
Component: | [OLD] Core system | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | VERIFIED UPSTREAM | ||
Severity: | critical | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Robert Bradbury
2008-02-13 01:08:36 UTC
And this is a Gentoo-specific issue exactly why? What are you expecting from us? Jakub, I thought I would start with Gentoo because "uname -a" indicates the kernel is "PREEMPT" which I presume to mean it is "preemptive". I was hoping that meant it was tuned for desktop use but this bug report suggests it is not. If you feel it isn't a Gentoo problem, then I would like suggestions as to: a) what news group, blog, BBS, etc. I should post it to for feedback; and/or b) precisely where one goes to file a Linux kernel bug report (to the best of my knowledge there is no bugzilla database). I am aware that there have been some "wars" in the past (a year ago or more) regarding configuration of the kernel for desktop vs. server use (including changing changing vm.swappiness settings but I've never noticed much difference in the system behavior when I change that and I thought the kernel had been modified to resolve these problems. If you resolve a bug as UPSTREAM, the bug report should point to where the bug report has been filed. Well... so for you issues - if you complain about kernel design, that's what LKML [1] is for, but... you'd better get some insight first on the inner workings of that thing to not have completely unrealistic expectations - such as that spawning infinite number of processes which exhaust all available RAM should leave your system perfectly responsive. It will become responsive again once OOM killer has done its job. :P And yeah, swap is slower than RAM as well, by several orders of magnitude. ;) Wrt FF, the 2.0 series still uses X server as storage for uncompressed images, so wondering why X server CPU usage skyrockets when you launch hundreds of windows with thousands of tabs is uhm... kinda weird. There's no point in filing any bugs about it, FF3 is completely reworked wrt this, you can try the (unsupported!) ebuilds from mozilla overlay [2] [1] http://lkml.org/ [2] http://overlays.gentoo.org/proj/mozilla/browser/www-client/mozilla-firefox Closing, there's nothing we could fix here, at all. Actually there is something that can be done about this bug by Gentoo and that is to have the default system login definitions for use process limits be more reasonable. The shell is about 700 kb, so a reasonable process limit might be of the form: /proc/meminfo [MemTtotal] / 700 which works out to ~2200 on my system. Or given scans of my "typical" process usage perhaps between 200 and 400. Then have the default login do a ulimit -Su $NUMPROC_LIMIT. The OOM killer is a very bad solution as I believe it kills the largest processes first (which in my case would be firefox, X and open office) -- not runaway recursive shells or shells and makes (in which case it should be looking at the process count per process name and the process creation times/rates). |