lkml.org 
[lkml]   [2017]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 1/6] kmod: add dynamic max concurrent thread count
    On Thu, May 25, 2017 at 12:01 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
    > On Thu, May 25, 2017 at 11:26 AM, Dmitry Torokhov
    > <dmitry.torokhov@gmail.com> wrote:
    >> On Thu, May 25, 2017 at 08:06:03PM +0200, Luis R. Rodriguez wrote:
    >>> On Thu, May 25, 2017 at 10:38:40AM -0700, Luis R. Rodriguez wrote:
    >>> > On Thu, May 25, 2017 at 10:30 AM, Dmitry Torokhov
    >>> > > There is
    >>> > > no slippery slope for systems to move away, no need to backport
    >>> > > anything. We seem to agree that a better solution is possible (throttle
    >>> > > number of concurrently running modprobes without killing requesters),
    >>> > > and with that solution the band-aid will no longer be needed.
    >>> > >
    >>> > > So please implement and post the proper fix for the issue.
    >>> >
    >>> > Alright, will do away with this patch and just go for the jugular of the issue.
    >>>
    >>> I gave this some more thought, even if we go with the throttling right away in
    >>> practice you'll end up with a dmesg notice of a throttle kicking in once you *do*
    >>
    >> So remove it. The warning was meaningful when we rejected requests, now
    >> it is not.
    >
    > Great.
    >
    >>> reach this. We are forcing only 50 concurrent threads and making this a static
    >>> limit with no good reason than 2.3.38 days evaluation from 16 years ago (2000).
    >>> If we throttle we are going to throttle with a 2.3.38 days limit. And you
    >>> advocate that ?
    >>
    >> Yes. Can you give me reason why slamming the system with more than 50
    >> modprobes is a good idea in 4.12 days? Does the increased limit
    >> decreases boot time? By how much?
    >
    > If in practice we are not hitting the limit the point is moot, and
    > when we do I agree we can re-evaluate. With my stress test driver on a
    > test case we can push as hard as bringing out the OOM killer even if
    > we throttle, fun.

    Alright, I don't see these OOMs anymore *after* I actually nuked that
    patch which incremented the kmod limit. The reason we can OOM is
    finit_module() can consume gobs of memory, the current value then
    seems fair, and work well for my tests provided we do use the proper
    throttle. Will respin.

    Luis

    \
     
     \ /
      Last update: 2017-05-25 23:39    [W:4.213 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site