[lkml]   [1998]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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...

    | Linux memory management tour guide. |
    | Scouting Vries cubscout leader. |

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:43    [W:0.022 / U:15.544 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site