>Last time I looked into the inode stuff, it seems that it never frees
>memory. So, except for systems that use an inode table that will grow up
Yes it never releases it's memory. This is why I called them
fragmenting `bomb' ;).
>to a large part of the memory, this change will be not better than a
>placebo, and placebo are known to only work with humans for the moment.
It's not only a band-aid, it's a nice/simple change that may also improve
performances (just a bit of course ;). And it avoids completly the inode
allocation to cause problems to the fragmentation of the
2-contiguous-pages layer of the VM.
>Btw, if the inode stuff would free memory on demand (8k on 4K page
>systems), then it would just behave as a 8k chunks pool for the fork
>not to fail.
The icache is designed to be presistent and the reason of my patch is
just to avoid that its persistence could harm the VM.
>If we would apply that 8k granularity allocation to all parts that
>allocate memory, then we would get a system that uses 8k pages virtualized
>over 4k hardware virtual pages. ;-)
>
>Since you seem to be a kernel champion, instead of implementating minute
Thanks ;)
>patches, you should for example try to implement the following:
>
>1) Implement the virtualized kernel stack and fix any driver you are
> using and that DMAs the stack. I can help you for that, but I
As just said using always vmalloc is not an option according to me (and to
DaveM if I remeber well) for performances.
And more important as far as there are 2-pages chunks available in the VM,
using vmalloc is _not_ needed.
>3) Now that you have got rid of the 8k allocation fork problem, you can
> also get rid of everything that tried to deal with this problem and
> simplify some parts of the kernel.
As just said the inode change is not a band-aid. It would be sure better
even if our kstack would be of only 1 page.
But to convince me in going into this, please apply this my debugging
patch and let me know if you can cause the kernel to really print such
message on the console (or in your logs).
Index: kernel//fork.c
===================================================================
RCS file: /var/cvs/linux/kernel/fork.c,v
retrieving revision 1.1.2.9
diff -u -r1.1.2.9 fork.c
--- fork.c 1999/03/09 01:24:06 1.1.2.9
+++ linux/kernel/fork.c 1999/03/15 01:00:36
@@ -640,6 +640,13 @@
unlock_kernel();
up(¤t->mm->mmap_sem);
fork_out:
+ {
+ extern int nr_free_pages;
+ if (nr_free_pages)
+ printk(KERN_DEBUG
+ "fork: can't alloc the kernel stack due "
+ "VM fragmentation\n");
+ }
if ((clone_flags & CLONE_VFORK) && (retval > 0))
down(&sem);
return retval;
Andrea Arcangeli
-
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/