lkml.org 
[lkml]   [1998]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Strange interrupt behaviour


    On 12 Jul 1998, Andi Kleen wrote:
    >
    > When Ingo tells us that the current 2.1 tree barely works with about
    > 7K stack then this opens the question: Where is all this spend?

    Ingo didn't say anything at all like that.

    Ingo said that 2.0.x had problems operating with a 4kB stack. We had
    issues with stack frames being big with various SCSI device drivers, and
    that together with certain filesystems having a big stack (umsdos was the
    worst), led to various very-hard-to-explain problems for some people.

    We solved it by making sure that some of the worst offenders were fixed,
    but the point is that 4kB of stack is not all that much.

    In 2.1.x, we have a _very_ clever scheme for the "current" pointer, that
    speeds up both SMP and UP, and makes them both behave exactly the same
    way. However, in order to do that clever scheme, the "stack area" was
    expanded to not only contain the stack, but also contain the "current"
    task structure.

    This had the advantage of generally speeding things up, but it made a lot
    of other sense too - for example you now only need one allocation for both
    stack and "struct task_struct", and so "fork()" was faster.

    However, "struct task_struct" is fo a non-negligible size, as it has to
    have all the process information, and trying to fit both the stack and
    that into 4kB was simply not an option. So we expanded the common area to
    be 8kB - it's not that the stack grew, it's just that we needed to fit
    other things than the stack in the same area.

    The fact that the "struct task_struct" is smaller than 4kB and the usable
    stack area grew is a side effect, it's not the reason. 2.1.x does not need
    any more stack than 2.0.x needed.

    vmalloc() is not acceptable.

    Getting 8kB allocations shouldn't be too hard - it's just that the current
    mm/page_alloc.c gives up a bit too easily as a backlash against it never
    giving up at all in certain 2.1.x kernels. It's a balancing issue, and
    getting rid of the 8kB allocation is not the answer.

    Linus


    -
    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.altern.org/andrebalsa/doc/lkml-faq.html

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