From: "Chris Evans" <[EMAIL PROTECTED]>
>
> I thought (on Intel) there was a 4092 hard limit?
>
That's the 2.2 limit, it's gone.
The new limit is total memory and pid space. The pid's are intentionally
limited to 15 bits, the remaining bits are reserved.
In the worst case one running process can
On Tue, 13 Mar 2001, Manfred Spraul wrote:
> * bugfixes for get_pid(). This is the longest part of the patch, but
> it's only necessary if you have more than 10.000 threads running. If you
> have enough memory: launch a forkbomb. If ~ 32760 thread are running the
> kernel enters an endless loop
>
> Maybe it would be good to lower the default threads-max to
> about 10% or less of physical memory ?
>
And MIN_THREADS_FOR_ROOT should be reintroduced: the define is still
there, but the actual code is missing.
I've attached an older patch that:
* reintroduces MIN_THREADS_FOR_ROOT (or remo
On Tue, 13 Mar 2001, Mike Galbraith wrote:
> (A workaround is to lower max_threads to 25% of memory.. works, but is
> really cheezy. OTOH, allowing half of memory to be allocated in task
> structs is a bit cheezy looking too. That means that these tasks
> can't be big enough to be doing real wo
On Tue, 13 Mar 2001, David Shoon wrote:
> Hi,
Greetings,
> After some testing, 2.4.2, 2.4.2-pre3, and 2.4.3-ac18 and ac19 both
> crash/hang when a fork loop (bomb) is executed (under a normal user) and
> killed (by a superuser). This isn't what you'd expect in previous
> kernels (2.2.x, and 2.0
Hi,
After some testing, 2.4.2, 2.4.2-pre3, and 2.4.3-ac18 and ac19 both
crash/hang when a fork loop (bomb) is executed (under a normal user) and
killed (by a superuser). This isn't what you'd expect in previous
kernels (2.2.x, and 2.0.x), as they both return to normal after killing
the process.
6 matches
Mail list logo
