> On 7 Jul 1998, Kip Rugger wrote:
>
> > Recent 2.1 kernels suffer memory fragmentation, eventually requests >4kB
> > start failing. Among these are the requests made by fork for an 8kB kernel
> > stack.
> >
> > This little hack changes fork to use the vmalloc service, so that the 8kB
> > fork request can be satisfied with 2 non-contiguous 4kB pages.
>
> The fork request can, yes. But the kernel stack definately
> requires 8 kB of physically contiguous memory!
>
> I guess you run a lightly loaded machine and haven't hit
> the 4 kB point on your kernel stacks yet... With your patch
> there's a good chance that such an event could:
> - scribble over other memory
> - even swap out (!) and zero out that other memory
> - thus zero out the part of the 'stack' we were working
> on and in the process kill some memory of other processes
Rik, have you read the patch? It is allocating a _virtually contiguous_
kernel stack, so it will definitely work on some boxes. It's using
vmalloc(), vmalloc-ed areas are _never_ supposed to be swapped out. Our
swapout code is vma based and vmalloc() doesnt use vmas, it uses it's own
private list ...
besides performance another problem with the patch is that certain drivers
allocate SCSI structures on the kernel stack and do DMA to it. I have
found out the hard way when i tried to implement vmalloc()-style kernel
stacks (see the MMU kernel patch stack) 2 years ago. While this could
theoretically be fixed (the driver), and while on certain architectures we
use an MMU stack (certain Sparcs), it's generally a good idea to have all
kernel memory 'directly' mapped, it's a robust concept.
fix the allocator (or the whole kernel memory concept), not the symptom
...
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu