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 8DEBDC54FD0 for ; Thu, 23 Apr 2020 06:36:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4EB472074F for ; Thu, 23 Apr 2020 06:36:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="amfkG7St" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4EB472074F 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 CE01B8E0006; Thu, 23 Apr 2020 02:36:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C90DA8E0003; Thu, 23 Apr 2020 02:36:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA66A8E0006; Thu, 23 Apr 2020 02:36:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0143.hostedemail.com [216.40.44.143]) by kanga.kvack.org (Postfix) with ESMTP id A0D5A8E0003 for ; Thu, 23 Apr 2020 02:36:00 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 38DFF181AC9CB for ; Thu, 23 Apr 2020 06:36:00 +0000 (UTC) X-FDA: 76738159680.15.queen52_6e96c8e94b95a X-HE-Tag: queen52_6e96c8e94b95a X-Filterd-Recvd-Size: 5165 Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Thu, 23 Apr 2020 06:35:59 +0000 (UTC) Received: by mail-io1-f67.google.com with SMTP id b12so5223432ion.8 for ; Wed, 22 Apr 2020 23:35:59 -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=cn7vIBTAgIB4yIOyzKzjZn//S/wFQhqS8zDFmMiRXTE=; b=amfkG7StXZTf7/8r6RIpOKC4a7snQLPJ7RX6IfcJyjNpNwNsGhMt7fK7p2Xc4p0Mmj wcsJQgVTsvhMkZPF5yz0gq5xmKPDpU4jcQgd4xayKR/tBx1ipg3jlwV/9ZVYN9JD01uD /45x+lFUa2BvSIDIsl+Qwf/cg1vf/5r+RT/eFL7p/dE49e/eUQl3T983z4Y2n51waSQI XdNMFz4anGfGYQ9NJ0TQgt7r0/tlQgZpEy3b+fgdNx7PazoYxr2ZgbDEcYeTwgZN7PCh 5eKQj6Gk7IzBEHemMGq7/s2bk7Owz0uykdAgc46ERNL1YEussVMNqRXHrQXICvZbHTnM Et2w== 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=cn7vIBTAgIB4yIOyzKzjZn//S/wFQhqS8zDFmMiRXTE=; b=uCjiodHIwp7ZxLufOfda8Dt3KBP9jOh0wQdc+EMoi8k4DkTjc6qr95E9GeDqMfwfT+ ydOd1MxXwxYYoxGdZdXKu8QkMtNZ6xbbn6m3/lv0j8QpyeE5nYzPsecBNb6jj7rvSBH+ n/1lojTj6QZ5dwKsj+uRAH4YyKK4070N4TEozfXp9CHrO8Ri+QeWlecLcSY3pgfHrgVJ ftC732kJ+jfsUQBwu4pDSdwBpBAOXOWcP2icP3E9elmNMYTOC3uMaCy1I8TfTqXefJr8 gFyJEhxP9CutlT9qovarzJ9wdSH63epdXud5/Alww4SCa0iCB5oFQYABON1TrrW88mXe 8AlQ== X-Gm-Message-State: AGi0Puag7tGrkndp+u6gjCrzKvu2tQUMSOboiu0c2KHt9Z6QDsMRB59m rEKOicxWOJX1hUI6SdWR0O22p1giT3InTRkzg08= X-Google-Smtp-Source: APiQypLJz95NqptGnZil4jDIeKmhf55G9jdEBd3FWM8JATIn2oMFE4kNLZH3KT/ysWYRojVbR84jq0ciUmyvU0loSbY= X-Received: by 2002:a6b:7843:: with SMTP id h3mr2313315iop.202.1587623758313; Wed, 22 Apr 2020 23:35:58 -0700 (PDT) MIME-Version: 1.0 References: <20200131043324.wkArXTf6-%akpm@linux-foundation.org> <20200417152637.GQ26707@dhcp22.suse.cz> <68371d79-dfae-e9b9-38df-dbb916607a82@i-love.sakura.ne.jp> <20200420073305.GD27314@dhcp22.suse.cz> <041d4158-f3dc-a5b5-546e-dd3f71f67b5f@i-love.sakura.ne.jp> <20200422065950.GA30312@dhcp22.suse.cz> <0aa5e490-c5b8-dc5c-334e-9a8d37da215c@i-love.sakura.ne.jp> In-Reply-To: <0aa5e490-c5b8-dc5c-334e-9a8d37da215c@i-love.sakura.ne.jp> From: Yafang Shao Date: Thu, 23 Apr 2020 14:35:22 +0800 Message-ID: Subject: Re: [nacked] mm-oom-avoid-printk-iteration-under-rcu.patch removed from -mm tree To: Tetsuo Handa Cc: Michal Hocko , Andrew Morton , Roman Gushchin , linux-mm , David Rientjes , Shakeel Butt Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.002291, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Apr 23, 2020 at 1:35 PM Tetsuo Handa wrote: > > On 2020/04/22 15:59, Michal Hocko wrote: > >>> This is what the async printk will address > >>> AFAIU. > >> > >> No! You are completely wrong!! Async printk CANNOT reduce the amount of the > >> output. > > > > Which is exactly what I claim above. Async printk would, however, deal > > with the problem of the locked context part of the problem because > > the heavy lifting is not done from the caller context. Please read my > > response carefully. > > No! My proposal (which offloads to a deferrable context) avoids doing the > heavy lifting (for printk buffer users) from the printk caller context. I'm > saying that "don't pile up too much backlog onto the printk buffer (by abusing > async printk) in order to make sure that kernel messages which are more > important than reporting OOM victim candidates will be processed immediately". > > dump_tasks() remains definitely a printk() abuser which is capable of pushing > many thousands of printk() messages in one second if async printk were available. > Async printk CANNOT deal with the problem that too much backlog causes important > messages to be delayed for too long. Please read my explanation carefully. > Agreed. Too much oom reports still be a issue even if the printk() is asyn. I think the aysnc printk() won't care about wheter the data is improtant or not, so the user of printk() (even if it is asyn) should have a good management of these data especially if these data may consume all or most of the printk buffer. > Also, Sergey Senozhatsky (printk maintainer) said at > https://lkml.kernel.org/r/20200423015008.GA246741@jagdpanzerIV.localdomain > that it is UNKNOWN when async printk is merged. Async printk is not a > silver-bullet breakthrough. Async printk cannot work without cooperation from > printk() users. Please really stop letting the printk() do the heavy lifting. > -- Thanks Yafang