Hi list,
I've run into memory problems. I'm experimenting with Gimp, and working
with relatively large images (3000 x 3000 pixels). I'm also working with
large fonts (>100 pixels).
Problem is that the kernel VM layer starts to kill my processes when
they get really big re. memory footprint. Here are the massages from the
kernel:
Jun 12 10:53:13 piglet kernel: VM: killing process gimp
Jun 12 10:55:03 piglet kernel: VM: killing process X
Jun 12 10:59:46 piglet kernel: VM: killing process X
Jun 12 12:04:27 piglet kernel: VM: killing process xfs
and so on... acording to the comment in arch/ppc/mm/fault.c, this
happens when for some reason the kernel cannot satisfy a paging request.
xfs gets killed when rendering a really big font, X when sending it over
to gimp, and gimp when working with large images....
What reason is there to kill a process for memory reasons? Does a single
process need to fit _entirely_ into RAM, or can part of a process be
swapped out? In all of the above cases, I've always had over 100 megs of
swap free. Or is there a fixed limit on how big a process can get?
Thanks
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Mon, Jun 12, Michel Lanners wrote:
Jun 12 10:53:13 piglet kernel: VM: killing process gimp
Jun 12 10:55:03 piglet kernel: VM: killing process X
Jun 12 10:59:46 piglet kernel: VM: killing process X
Jun 12 12:04:27 piglet kernel: VM: killing process xfs
and so on... acording to the comment in arch/ppc/mm/fault.c, this
happens when for some reason the kernel cannot satisfy a paging request.
xfs gets killed when rendering a really big font, X when sending it over
to gimp, and gimp when working with large images....
What reason is there to kill a process for memory reasons? Does a single
process need to fit _entirely_ into RAM, or can part of a process be
swapped out? In all of the above cases, I've always had over 100 megs of
swap free. Or is there a fixed limit on how big a process can get?
It is only self protection of the kernel to run not out of memory.
The last process that want to allocate memory when memory is low gets
killed. Looks like that is not smart enough when swap is still
available.
Gruss Olaf
--
$ man clone
BUGS
Main feature not yet implemented...
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Jun 12 10:53:13 piglet kernel: VM: killing process gimp
Jun 12 10:55:03 piglet kernel: VM: killing process X
Jun 12 10:59:46 piglet kernel: VM: killing process X
Jun 12 12:04:27 piglet kernel: VM: killing process xfs
and so on... acording to the comment in arch/ppc/mm/fault.c, this
happens when for some reason the kernel cannot satisfy a paging request.
xfs gets killed when rendering a really big font, X when sending it over
to gimp, and gimp when working with large images....
What reason is there to kill a process for memory reasons? Does a single
process need to fit _entirely_ into RAM, or can part of a process be
swapped out? In all of the above cases, I've always had over 100 megs of
swap free. Or is there a fixed limit on how big a process can get?
There's a limit on process VM size but that's quite large and shouldn'
affect you there. I'd look into the exact reason why the kernel could not
satisfy a paging request in your specific case. You might be attempting to
free pages in order to swap in what you need but kswapd didn't succeed in
swapping out anything. Or maybe there's nothing left on any of the free
lists that are used by __get_free_page(GFP_USER). How much swap space
remains is meaningless as long as there isn't any page in RAM that's "old"
enough to be swapped out.
Try to adjust the page aging parameters to make kswapd more aggressive
about swapping out stuff that's only moderately old (probably done via
/proc/sys/vm/kswapd). Or add some debug code to __get_free_pages to find
out where it gets stuck (i.e. is the paging request even happening at a
stage where the number of free pages is below the highwater mark for
kswapd).
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/