lkml.org 
[lkml]   [2000]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectSMP 2.2.14/15pre10: fork() fails with -ENOMEM during alloc_task_struct
Date
Greetings,

While running each of the kernels 2.2.13, 2.2.14, 2.2.15pre9, and
2.2.15pre10, I have encountered conditions on an SMP 4-CPU machine
where the fork() system call fails to allocate a task_alloc_struct
and returns ENOMEM to the caller.

At the time of the failed system call, there is plenty of memory
(128meg of 1 gig), and certainly another gigabyte of swap (300k
used) at the time of the no memory error.

Other things I have checked are:
* there are far less than 512 processes running (NR_TASK = 4090);
* there is plenty of free memory immediately following the failed system call;
* there doesn't appear to be inordinate memory leaks in the kernel itself
- but how to tell?

I attempted to place a spinlock around the old code that is in
arch/i386/kernel/process.c (which is deactivated in SMP mode
on the assumption that get_free_page(GFP_KERNEL) will return
the correct value) which maintains a small stack of 16 previously
allocated task_alloc_struct's, but thought of certain deadlock
SMP race conditions on the way home that evening, and sure enough -
the machine locked solid a few hours later.

Things I will be trying in the meantime:
* change the application to try again to fork "a little later" "several" times;
* change the application to not abort on a failed fork;
* change the application's parent to not abort when its co-routine aborts;
* change the application's parent to not need the forking process in the
first place.

These are all work-arounds for what should be a non-error in the first place.

So my questions are:

1. under what conditions would get_free_page(GFP_KERNEL) return
NULL (no available page) when it appears there is free memory?

2. other than watching the output of Shift-ScrollLock periodically,
what other ways are there to spot memory usage in the kernel?

3. 'ps -vax' shows interesting behaviour, but the sum-total of
each of RSS and allocated memory are less than physical memory,
and 'swapon -l' shows very little allocated swap. It doesn't
appear that I am trigger the OOM kill-process behaviour of
the kernel from being overcommitted. How can I confirm this?

4. Is anyone else interested in tackling this sort of problem in the
developer community? The application is a massively multi-player
game. :)

Best regards,
Andy

PS - I read the list via muc.lists.linux-kernel, but emailed responses
will also be watched - assuming I have procmail configured correctly.
:) -A


--
Andrew Finkenstadt (http://www.finkenstadt.com/andy/)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.099 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site