lkml.org 
[lkml]   [2016]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 1/2] mempool: do not consume memory reserves from the reclaim path
    On Thu, Jul 21, 2016 at 10:52:03AM +0200, Michal Hocko wrote:
    > Look, there are
    > $ git grep mempool_alloc | wc -l
    > 304
    >
    > many users of this API and we do not want to flip the default behavior
    > which is there for more than 10 years. So far you have been arguing
    > about potential deadlocks and haven't shown any particular path which
    > would have a direct or indirect dependency between mempool and normal
    > allocator and it wouldn't be a bug. As the matter of fact the change
    > we are discussing here causes a regression. If you want to change the
    > semantic of mempool allocator then you are absolutely free to do so. In
    > a separate patch which would be discussed with IO people and other
    > users, though. But we _absolutely_ want to fix the regression first
    > and have a simple fix for 4.6 and 4.7 backports. At this moment there
    > are revert and patch 1 on the table. The later one should make your
    > backtrace happy and should be only as a temporal fix until we find out
    > what is actually misbehaving on your systems. If you are not interested
    > to pursue that way I will simply go with the revert.

    +1

    It's very unlikely that decade-old mempool semantics are suddenly a
    fundamental livelock problem, when all the evidence we have is one
    hang and vague speculation. Given that the patch causes regressions,
    and that the bug is most likely elsewhere anyway, a full revert rather
    than merely-less-invasive mempool changes makes the most sense to me.

    \
     
     \ /
      Last update: 2016-07-21 14:41    [W:2.631 / U:0.608 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site