Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1644374ybe; Fri, 6 Sep 2019 23:36:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqxbG/x03DRDBJh5iYYlpfOQWCFQwcyJVASu7fOX2ntTdDqWcTe00oPuPv8LSDpdtSTLKQoc X-Received: by 2002:a17:90a:8509:: with SMTP id l9mr10231936pjn.10.1567838190208; Fri, 06 Sep 2019 23:36:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567838190; cv=none; d=google.com; s=arc-20160816; b=uZtePYxZ9JvxZ/wiKYr6nCzoiuO740hhzENf3lXL9YhTABjoYMlnJpcas/SCcTl6TT rIqpvHdAoRANsrwvJySr8+FUFd5uLQg5jM4cTM7MggihETJiFVwVJm6HPBRWrpWkm/Xp ETRcGR9dyGjGp7mxyJcItjKRlUm8RpKQXRoHmWKlkfpvvGaiWSi3or3uDHxZqt5+B4Fu qyUtw+cq+ZRAvUCQgeQyeaLkdshiwY+TyI3FzxpiHbRHIKxh57Oa/HE+2+ioqIiZl5CF iOQ2HbMYzs65RbDgaLObhJv6bFtW8QQm7pkOeqgdbT/znbEqiEvbc4Ud0GYBb9zg6oyp ZUfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=hGnSwCVr+EHrh4sJs7JyBFLvqrbF+iGNOvafEbRZH8k=; b=d5uWKRV7e2Aw4ui7PL04QxrUUxZYSfM55y/Wd28B/okwu1v9TtziqJgKILXpvyPrq3 ALmBsjkRueHoJAjvWgkiW8M4sQnOv6CZfOUxN0l3Q0KZNl0BBrrqGra3sTEexi+CNW7i O9ByHphDmO369SblAMKT/vUJ1ybaH1JgPx0TnqN+lbpeu9ghqJZP/Jnou1b2dp4NAXaJ YlFS0dz2DLwf/2OPE9UzL99lH67qnFrNB2zohnT9+irrHV9C7MZGKF9EQ49BmslfZc8F 96nC240KiYHOb5MyBeNyfyfViIJfKMhKhnLVEi8/IxhFdGuKxqPIB4FkDorvH4iyE515 2iJA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u21si6366422pgn.290.2019.09.06.23.36.15; Fri, 06 Sep 2019 23:36:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394842AbfIFPcM (ORCPT + 99 others); Fri, 6 Sep 2019 11:32:12 -0400 Received: from mx2.suse.de ([195.135.220.15]:51010 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725871AbfIFPcL (ORCPT ); Fri, 6 Sep 2019 11:32:11 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 22975AD69; Fri, 6 Sep 2019 15:32:10 +0000 (UTC) Date: Fri, 6 Sep 2019 17:32:09 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: Steven Rostedt , davem@davemloft.net, Eric Dumazet , Sergey Senozhatsky , Michal Hocko , linux-mm@kvack.org, Qian Cai , linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH] net/skbuff: silence warnings under memory pressure Message-ID: <20190906153209.ugkeuaespn2q5yix@pathway.suse.cz> References: <20190904064144.GA5487@jagdpanzerIV> <20190904065455.GE3838@dhcp22.suse.cz> <20190904071911.GB11968@jagdpanzerIV> <20190904074312.GA25744@jagdpanzerIV> <1567599263.5576.72.camel@lca.pw> <20190904144850.GA8296@tigerII.localdomain> <1567629737.5576.87.camel@lca.pw> <20190905113208.GA521@jagdpanzerIV> <20190905132334.52b13d95@oasis.local.home> <20190906033900.GB1253@jagdpanzerIV> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190906033900.GB1253@jagdpanzerIV> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 2019-09-06 12:39:00, Sergey Senozhatsky wrote: > On (09/05/19 13:23), Steven Rostedt wrote: > > > I think we can queue significantly much less irq_work-s from printk(). > > > > > > Petr, Steven, what do you think? > > [..] > > I mean, really, do we need to keep calling wake up if it > > probably never even executed? > > I guess ratelimiting you are talking about ("if it probably never even > executed") would be to check if we have already called wake up on the > log_wait ->head. For that we need to, at least, take log_wait spin_lock > and check that ->head is still in TASK_INTERRUPTIBLE; which is (quite, > but not exactly) close to what wake_up_interruptible() does - it doesn't > wake up the same task twice, it bails out on `p->state & state' check. I have just realized that only sleeping tasks are in the waitqueue. It is already handled by waitqueue_active() check. I am afraid that we could not ratelimit the wakeups. The userspace loggers might then miss the last lines for a long. We could move wake_up_klogd() back to console_unlock(). But it might end up with a back-and-forth games according to who is currently complaining. Sigh, I still suggest to ratelimit the warning about failed allocation. Best Regards, Petr