From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F6D9C38A2B for ; Fri, 17 Apr 2020 11:58:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 063D921D94 for ; Fri, 17 Apr 2020 11:58:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="uzhK1rRG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 063D921D94 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8DD598E000F; Fri, 17 Apr 2020 07:58:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 866708E0001; Fri, 17 Apr 2020 07:58:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7548D8E000F; Fri, 17 Apr 2020 07:58:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id 573378E0001 for ; Fri, 17 Apr 2020 07:58:15 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1F765583A for ; Fri, 17 Apr 2020 11:58:15 +0000 (UTC) X-FDA: 76717198950.16.look83_6518a54037808 X-HE-Tag: look83_6518a54037808 X-Filterd-Recvd-Size: 5713 Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Fri, 17 Apr 2020 11:58:14 +0000 (UTC) Received: by mail-il1-f195.google.com with SMTP id t10so1830419ilg.9 for ; Fri, 17 Apr 2020 04:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QTqYSeJ3wvQH+LL7dRQHL8EwwtGA06HJ0dXL/sQXhYs=; b=uzhK1rRGZRZwXdHmqizai+SwTvrs2vSapbhJAaZZjMTiOQdd/OqnMaXFR0xzwsAh3U 4GGTW12c69GogtXyxLHzYnnmi9rAOnyDb/TEMNebksgoVMyzf+k2t117BZYKS8rNkUvz EeUKGsbYqXOQz2Qu3y85lFfe4rMRgy/gchuuCwaRyn/vXx6CxFQUrDj07zFWnRnwZRpG cmxb16ijPtECg7VF+Om0jSsfOsBonLpCHr+LfpkQLXIwXjvLSSt2+q5tj0h0F8cgjVVl UBUTv2Gnh78BRyRjxrpRm5KrCFfApaiAvc+Wz9S2Oo1boSCCkpW5lLmU4RTVmg8AERaU KJHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QTqYSeJ3wvQH+LL7dRQHL8EwwtGA06HJ0dXL/sQXhYs=; b=j7uTdrgqtoKDxlVb16eZWMPy3C9s8Z6RAyNvBYq2yojeMK6U9lZ8SY16M7Ut8Dfxno 8F6QwoxvG+MGf9yZGJJo96I+5i5Hzg2Vwgtxa8g/xByhXBcQyG87lQInIrwHqvtVsU15 AZYzqaPmghtLKfPFWs0S9X5dC6HWMHqXopxOjDV0/lmttRUfCZkSvYJLu4ibdePfKWrE ETcRI9a1HVGZyJUiG0AhZnLWE4ZBIOO3uem/m5IvIktsdweok0x8HCLcxs8NBAogpOzT ZyfVwWTzDv22m8EfP3xalXdTvEZbD9wUk+pYYF0Ds4LGM15nM2aiMimwWgnPJh/NWVrr QvYQ== X-Gm-Message-State: AGi0Pua2nz+yNd+YQEP7VYPGRSnUBnBPAC44S8XPCcxX2YU2k8zXNRrg BVQ02rNosM86km+7+OdQOJfh/Av+hBzKqyAcAvo= X-Google-Smtp-Source: APiQypLCKmt2eerLCWuXiq9bA97vsqzkL33dTmbRP9jjJDA9yWGeJKXexVMshhRG/6F1u0KYZ2A9/r1pJ3wL4kea3mI= X-Received: by 2002:a92:9a4d:: with SMTP id t74mr2698808ili.168.1587124694020; Fri, 17 Apr 2020 04:58:14 -0700 (PDT) MIME-Version: 1.0 References: <1586597774-6831-1-git-send-email-laoar.shao@gmail.com> <20200414073911.GC4629@dhcp22.suse.cz> <20200414143229.GN4629@dhcp22.suse.cz> <634bab6a-fee1-45b8-62af-be03062ae2bf@I-love.SAKURA.ne.jp> In-Reply-To: <634bab6a-fee1-45b8-62af-be03062ae2bf@I-love.SAKURA.ne.jp> From: Yafang Shao Date: Fri, 17 Apr 2020 19:57:38 +0800 Message-ID: Subject: Re: [RFC PATCH] mm, oom: oom ratelimit auto tuning To: Tetsuo Handa Cc: Michal Hocko , Andrew Morton , Linux MM , Petr Mladek , Sergey Senozhatsky Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Apr 15, 2020 at 1:58 PM Tetsuo Handa wrote: > > On 2020/04/14 23:58, Yafang Shao wrote: > >>>>> The OOM ratelimit starts with a slow rate, and it will increase slowly > >>>>> if the speed of the console is rapid and decrease rapidly if the speed > >>>>> of the console is slow. oom_rs.burst will be in [1, 10] and > >>>>> oom_rs.interval will always greater than 5 * HZ. > >>>> > >>>> I am not against increasing the ratelimit timeout. But this patch seems > >>>> to be trying to be too clever. Why cannot we simply increase the > >>>> parameters of the ratelimit? > >>> > >>> I justed worried that the user may complain it if too many > >>> oom_kill_process callbacks are suppressed. > >> > >> This can be a real concern indeed. > > I'm proposing automated ratelimiting of dump_tasks() at > http://lkml.kernel.org/r/1563360901-8277-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp . > I believe that automated ratelimiting of dump_tasks() remains necessary > even after printk() became asynchronous. > Thanks for your information. I haven't read your proposal carefully, but take a first glance I think it would be a useful improvement. > >> > >>> But considering that OOM burst at the same time are always because of > >>> the same reason, > >> > >> This is not really the case. Please note that many parallel OOM killers > >> might happen in memory cgroup setups. > >> > >>> so I think one snapshot of the OOM may be enough. > >>> Simply setting oom_rs with {20 * HZ, 1} can resolve this issue. > >> > >> Does it really though? The ratelimit doesn't stop the long taking > >> output. It simply cannot because the work is already done. > >> > >> That being said, making the ratelimiting more aggressive sounds more > >> like a workaround than an actual fix. So I would go that route only if > >> there is no other option. I believe the real problem here is in printk > >> being too synchronous here. This is a general problem and something > >> printk maintainers are already working on. > >> > > > > Yes, printk being too sync is the real issue. If the printk an be > > async, then we don't need to worry about it at all. > > I strongly disagree. dump_tasks() will needlessly fill printk() log buffer > (and potentially loose other kernel messages due to buffer full / disk full). > Yup, printk() log buffer will be a issue if the console is too slow. After the printk() is implemented as async, I thinks it is worth to do some optimization. > By the way, Petr and Sergey, how is the progress of making printk() asynchronous? > When can we expect that work to be merged? > Thanks Yafang