lkml.org 
[lkml]   [2014]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RFC 2/2] x86_64: expand kernel stack to 16K
    From
    On Thu, May 29, 2014 at 5:50 PM, Minchan Kim <minchan@kernel.org> wrote:
    >>
    >> You could also try Dave's patch, and _not_ do my mm/vmscan.c part.
    >
    > Sure. While I write this, Rusty's test was crached so I will try Dave's patch,
    > them yours except vmscan.c part.

    Looking more at Dave's patch (well, description), I don't think there
    is any way in hell we can ever apply it. If I read it right, it will
    cause all IO that overflows the max request count to go through the
    scheduler to get it flushed. Maybe I misread it, but that's definitely
    not acceptable. Maybe it's not noticeable with a slow rotational
    device, but modern ssd hardware? No way.

    I'd *much* rather slow down the swap side. Not "real IO". So I think
    my mm/vmscan.c patch is preferable (but yes, it might require some
    work to make kswapd do better).

    So you can try Dave's patch just to see what it does for stack depth,
    but other than that it looks unacceptable unless I misread things.

    Linus


    \
     
     \ /
      Last update: 2014-05-30 04:01    [W:4.069 / U:0.204 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site