lkml.org 
[lkml]   [1998]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] fork failures on ix86
On Wed, 8 Jul 1998, MOLNAR Ingo wrote:
> On Wed, 8 Jul 1998, Rik van Riel wrote:
> > 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!
>
> 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

I wasn't talking about the vmalloc()ed area. I meant to
say that the 8kB piece allocated by fork() doubles as a
kernel stack for the process.
This can be very bad when a driver inside the kernel
expects a physically contiguous area and (as a result)
scribbles over other data that happened to be physically
contiguous to the first page of the stack.

Then there could occur a context switch which would swap
out that _other_ piece of memory, which happened to
contain a kernel stack piece of memory...

> 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

That is almost exactly what I said :)

> 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.

I'm busy on the allocator, but there are certain other things
that have priority right now. This is mainly because the
allocator probably isn't going to make it before 2.2 anyway.
It also is because I don't want another allocator that's been
put together in a hurry, I want one that supports _all_ wanted
and needed features. This takes some time to design properly...

Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [from the cache]
©2003-2011 Jasper Spaans