From patchwork Fri Jun 22 01:17:24 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mikulas Patocka X-Patchwork-Id: 10480999 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 0CC3960388 for ; Fri, 22 Jun 2018 01:17:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F14F01FFEB for ; Fri, 22 Jun 2018 01:17:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E4C8228574; Fri, 22 Jun 2018 01:17:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 620371FFEB for ; Fri, 22 Jun 2018 01:17:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CE0C96B0003; Thu, 21 Jun 2018 21:17:30 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id C68B76B0005; Thu, 21 Jun 2018 21:17:30 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B09C96B0006; Thu, 21 Jun 2018 21:17:30 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-qk0-f197.google.com (mail-qk0-f197.google.com [209.85.220.197]) by kanga.kvack.org (Postfix) with ESMTP id 8054D6B0003 for ; Thu, 21 Jun 2018 21:17:30 -0400 (EDT) Received: by mail-qk0-f197.google.com with SMTP id f2-v6so4240269qkm.10 for ; Thu, 21 Jun 2018 18:17:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:date:from:to :cc:subject:in-reply-to:message-id:references:user-agent :mime-version; bh=E1aqRpKSeSqQJmu6V5Ra2VuxVq244tSBErEmjvV8tD8=; b=s8NdSsCw/10PhZED3N+RH+NEEdwEpBt/KxQfGXul1iLJHYd9O2ShCL2wLAoOqwCUWb GLKynrRIdDXbn7jcskIxyy4B4fnIVt9DtjAr6ftOuNjlnbt5tqf37N93IhXaWJaARvOE ftKTUQB376XeKsZ9lpu4iIc68sXNvDNfy6e0PSR36WtadHnyudWBt/+hsxowHkcmp0ve sqxYSXKHlqKUhikUZ8+/cJVHuM7nWm8f040NbJqSUQs34ZJp6f4tMvHtlQgIo+eVS56i EZF7dvP1tB2ekisrsxqxDJSkp292y06/tuCN2OYG81OKkf2psXWxph//aNWfathU9KkH IVtw== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of mpatocka@redhat.com designates 66.187.233.73 as permitted sender) smtp.mailfrom=mpatocka@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com X-Gm-Message-State: APt69E1SkhNLJ6pr/4Ke/sYbYvR0ZDkTFtjUDDKY/76iwZcZ0zhjNaj+ /KU/Zx2PqGdN5z3UIv6tcExt/oc1zHMVsMGeFG1CfoaF4SQfS4T5yvoBRzJ/ZgM5QnIAJ46FvTh SFzceWA0jvcrkCtLpd7NV3Hv3wLpxoxBZqzjxT8UFQyrr3b2xBlSW4XkVzNtgZBH9Nw== X-Received: by 2002:ac8:285d:: with SMTP id 29-v6mr25641619qtr.61.1529630250295; Thu, 21 Jun 2018 18:17:30 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIdKK3VHQhpoTz58BQcTGq6jJayRZeUuIGkgkIdUCoJi1WjKmZv/mrQP+I4w+xPvxCxwFvw X-Received: by 2002:ac8:285d:: with SMTP id 29-v6mr25641570qtr.61.1529630249154; Thu, 21 Jun 2018 18:17:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529630249; cv=none; d=google.com; s=arc-20160816; b=cDOSS3v/J5GaMH1NbG1W8NhT2Xe6OSIZ/ZY8V7C4ylB4wKLlfaCm03cuVxTDQ4FKK4 vxRpYHKHGlqmFFn/bDcpF6o9v/HIMDFdNzez+9c3qPgdaF7bBUVefMLRiHpxmQW1mvnu xCkPSdtEZPRnfhi4BEN9lK4Ep1CHwXVe66VARczscvV8fNcbXJUJUI5xvuPjFTRdJO7s Si+bhQawPJtDpTBavqg/TeU4jMHEIPbz8gNQeBSwvkrhhD60RY7dedSe2IXiDeau4bEH ct9O1i0818Y1IoNp9C+8s9yEhEVDfH1GK7Q1VUwae1FGodkemWruY/bRBAEVXNuvg/7p pwcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:arc-authentication-results; bh=E1aqRpKSeSqQJmu6V5Ra2VuxVq244tSBErEmjvV8tD8=; b=FluAGLP4+ept/sIU0hIGib9bkRSFudh93zbWJhsUlvkRnIUi/0YgWjM9oTIGXNH+QA 6pFVsdMqeS6a21KCIKLqdYs50pxu/9viagUT5lxc3oqtoOSTkDQDey9ilNou14C4mn/t G8aPVIoxgaC0yGOBSq9dYzDZE8r0GgjiymNZ8bX8rd5nkEGWJSS7Htei/9TUL2qzetuS HGHj4R3+KHwOfA/IyL2cP3hST6QBKd69UjlIYkNaHyl9AR5qsrnLd2q1JexG4kFVlbGI fxhxzfndHBYnyw3C3l6PyLEkVGaSAyY2gOPsnEnSQ04DAAfXsMxF57kfM7hGtW+9HF2U 63mQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of mpatocka@redhat.com designates 66.187.233.73 as permitted sender) smtp.mailfrom=mpatocka@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from mx1.redhat.com (mx3-rdu2.redhat.com. [66.187.233.73]) by mx.google.com with ESMTPS id b29-v6si122914qkj.363.2018.06.21.18.17.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jun 2018 18:17:29 -0700 (PDT) Received-SPF: pass (google.com: domain of mpatocka@redhat.com designates 66.187.233.73 as permitted sender) client-ip=66.187.233.73; Authentication-Results: mx.google.com; spf=pass (google.com: domain of mpatocka@redhat.com designates 66.187.233.73 as permitted sender) smtp.mailfrom=mpatocka@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9B0468182D1F; Fri, 22 Jun 2018 01:17:28 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (file01.intranet.prod.int.rdu2.redhat.com [10.11.5.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 48AC5111DD1D; Fri, 22 Jun 2018 01:17:25 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (localhost [127.0.0.1]) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id w5M1HPtD016689; Thu, 21 Jun 2018 21:17:25 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id w5M1HOeB016685; Thu, 21 Jun 2018 21:17:25 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Thu, 21 Jun 2018 21:17:24 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Michal Hocko cc: jing xia , Mike Snitzer , agk@redhat.com, dm-devel@redhat.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: dm bufio: Reduce dm_bufio_lock contention In-Reply-To: <20180619104312.GD13685@dhcp22.suse.cz> Message-ID: References: <20180614073153.GB9371@dhcp22.suse.cz> <20180615073201.GB24039@dhcp22.suse.cz> <20180615115547.GH24039@dhcp22.suse.cz> <20180615130925.GI24039@dhcp22.suse.cz> <20180619104312.GD13685@dhcp22.suse.cz> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Fri, 22 Jun 2018 01:17:28 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Fri, 22 Jun 2018 01:17:28 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mpatocka@redhat.com' RCPT:'' 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: X-Virus-Scanned: ClamAV using ClamSMTP On Tue, 19 Jun 2018, Michal Hocko wrote: > On Mon 18-06-18 18:11:26, Mikulas Patocka wrote: > [...] > > I grepped the kernel for __GFP_NORETRY and triaged them. I found 16 cases > > without a fallback - those are bugs that make various functions randomly > > return -ENOMEM. > > Well, maybe those are just optimistic attempts to allocate memory and > have a fallback somewhere else. So I would be careful calling them > outright bugs. But maybe you are right. I was trying to find the fallback code when I triaged them and maked as "BUG" those cases where I didn't find it. You can search harder and perhaps you'll find something that I didn't. > > Most of the callers provide callback. > > > > There is another strange flag - __GFP_RETRY_MAYFAIL - it provides two > > different functions - if the allocation is larger than > > PAGE_ALLOC_COSTLY_ORDER, it retries the allocation as if it were smaller. > > If the allocations is smaller than PAGE_ALLOC_COSTLY_ORDER, > > __GFP_RETRY_MAYFAIL will avoid the oom killer (larger order allocations > > don't trigger the oom killer at all). > > Well, the primary purpose of this flag is to provide a consistent > failure behavior for all requests regardless of the size. > > > So, perhaps __GFP_RETRY_MAYFAIL could be used instead of __GFP_NORETRY in > > the cases where the caller wants to avoid trigerring the oom killer (the > > problem is that __GFP_NORETRY causes random failure even in no-oom > > situations but __GFP_RETRY_MAYFAIL doesn't). > > myabe yes. > > > So my suggestion is - fix these obvious bugs when someone allocates memory > > with __GFP_NORETRY without any fallback - and then, __GFP_NORETRY could be > > just changed to return NULL instead of sleeping. > > No real objection to fixing wrong __GFP_NORETRY usage. But __GFP_NORETRY > can sleep. Nothing will really change in that regards. It does a > reclaim and that _might_ sleep. > > But seriously, isn't the best way around the throttling issue to use > PF_LESS_THROTTLE? Yes - it could be done by setting PF_LESS_THROTTLE. But I think it would be better to change it just in one place than to add PF_LESS_THROTTLE to every block device driver (because adding it to every block driver results in more code). What about this patch? If __GFP_NORETRY and __GFP_FS is not set (i.e. the request comes from a block device driver or a filesystem), we should not sleep. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Index: linux-2.6/mm/vmscan.c =================================================================== --- linux-2.6.orig/mm/vmscan.c +++ linux-2.6/mm/vmscan.c @@ -2674,6 +2674,7 @@ static bool shrink_node(pg_data_t *pgdat * the LRU too quickly. */ if (!sc->hibernation_mode && !current_is_kswapd() && + (sc->gfp_mask & (__GFP_NORETRY | __GFP_FS)) != __GFP_NORETRY && current_may_throttle() && pgdat_memcg_congested(pgdat, root)) wait_iff_congested(BLK_RW_ASYNC, HZ/10);