lkml.org 
[lkml]   [2014]   [May]   [28]   [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
    [ Crossed emails ]

    On Wed, May 28, 2014 at 6:58 PM, Dave Chinner <david@fromorbit.com> wrote:
    > On Thu, May 29, 2014 at 11:30:07AM +1000, Dave Chinner wrote:
    >>
    >> And now we have too deep a stack due to unplugging from io_schedule()...
    >
    > So, if we make io_schedule() push the plug list off to the kblockd
    > like is done for schedule()....

    We might have a few different cases.

    The cases where we *do* care about latency is when we are waiting for
    the IO ourselves (ie in wait_on_page() and friends), and those end up
    using io_schedule() too.

    So in *that* case we definitely have a latency argument for doing it
    directly, and we shouldn't kick it off to kblockd. That's very much a
    "get this started as soon as humanly possible".

    But the "wait_iff_congested()" code that also uses io_schedule()
    should push it out to kblockd, methinks.

    >> This stack overflow shows us that just the memory reclaim + IO
    >> layers are sufficient to cause a stack overflow,
    >
    > .... we solve this problem directly by being able to remove the IO
    > stack usage from the direct reclaim swap path.
    >
    > IOWs, we don't need to turn swap off at all in direct reclaim
    > because all the swap IO can be captured in a plug list and
    > dispatched via kblockd. This could be done either by io_schedule()
    > or a new blk_flush_plug_list() wrapper that pushes the work to
    > kblockd...

    That would work. That said, I personally would not mind to see that
    "swap is special" go away, if possible. Because it can be behind a
    filesystem too. Christ, even NFS (and people used to fight that tooth
    and nail!) is back as a swap target..

    Linus


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