[lkml]   [1998]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] fork failures on ix86
    On Sat, Jul 11, 1998 at 12:59:43AM +0200, MOLNAR Ingo wrote:
    > On Fri, 10 Jul 1998 wrote:
    > > OK, then it has the same speed as before - maybe a bit slower because of
    > > the additional redirection. The big advantage of the trick Bernd suggested
    > > is that it makes the system much more reliable. It is very bad when Linux
    > > stops forking because memory is fragmented.
    > a 'bit' slower?? "current" is one of the most frequently used variables in
    > the kernel. (in 2.1.108 it's used ~5780 times througout the kernel source)
    > bloats code, uses up L1 cache.

    I doubt that it is that bad. It needs one additional cache line to access
    the bottom of the stack.

    Assuming you allocate the task_struct with the slab allocator which does
    proper L1 colouring and align on the most often used variable offset inside
    task_struct then for most processes this one cache line is saved again
    [the "fixed" alignment address at the bottom of the stack is bad for cache line
    selection on not fully associative caches]. With some reordering in
    task_struct it probably will be even faster.

    Of course this is all speculation without benchmarks, I'll run some tests

    > A 4k stack is not quite enough. it should be, but in RL it was pain and
    > caused way too common 'ayiee, stack corrupted ..' crashes. The current 7k
    > stack seems to be just about perfect, enough for all drivers/filesystems,
    > and still doesnt waste a full second page, because we have the task
    > structure there.

    That would be a killer of course. I was assuming that most of them
    were caused by "single offenders" like the aic7xxx driver putting lots
    of internal state on the stack - these could be fixed. If it is a more
    generic situation then it is not a good way.

    > put yet another way, if we cannot allocate 8k pages more or less reliably,
    > we are dead for NFS serving anyway ... and if we cannot allocate 8k pages
    > in fork() [which can wait, unlike the IRQ handler] we are doing way too
    > bad work too :(

    The NFS server can be easily fixed here - fork only with lots of black
    magic in the VM. Also it is reasonable to require lets say minimum 16MB
    of memory for a nfs server, while fork() is a much more fundamental
    operation that needs to work with minimum RAM reliable.


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

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