From patchwork Fri Jun 22 12:52:09 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mikulas Patocka X-Patchwork-Id: 10482051 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 C7F5460532 for ; Fri, 22 Jun 2018 12:52:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A819828C16 for ; Fri, 22 Jun 2018 12:52:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9C0EC28D70; Fri, 22 Jun 2018 12:52:13 +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 E8E0228C7F for ; Fri, 22 Jun 2018 12:52:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E7EEC6B000A; Fri, 22 Jun 2018 08:52:11 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id E30BE6B000C; Fri, 22 Jun 2018 08:52:11 -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 D1FCE6B000D; Fri, 22 Jun 2018 08:52:11 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-qt0-f197.google.com (mail-qt0-f197.google.com [209.85.216.197]) by kanga.kvack.org (Postfix) with ESMTP id A7BFA6B000A for ; Fri, 22 Jun 2018 08:52:11 -0400 (EDT) Received: by mail-qt0-f197.google.com with SMTP id a10-v6so5271054qtp.2 for ; Fri, 22 Jun 2018 05:52:11 -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=NjdL1QZQ8VObf+MLpsOx/tJP87w/vIzbdQicZaB92QA=; b=Dq9pe/8/7gvQ0HHg3hmwTkMuQZCgSB8mXS05rDxv217wf+PUmCSRQPCQcKyqszVxep OFNU1xsgTUfn+Gn+CUxY8/s1dQpGx13SQptxp+ijUsjQ/4sKAnzwJsHUf39ah/qu19OS 9ywxdZlVqi7+oVGsU/HuthGO/7sA/ic6FrvmyduebmyFGJ/7GBcBvEkIwLY+iBb6jW+f bLMrI8O0te+ptYjCFD0UcftNTT7zOgtUwNNsu5goMMats4buhhfBjdB1u3/IWPqSqYTs +NBG0Z051h/tQiA/v8G04y3Xgu49Hpr1xnWLAWw1vKLi0an7VrgFreg+2U6Cu3271Jyt 6cog== 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: APt69E2RowYA8ZqyCyqAkMe9MCKGQ/WdQylKsX1ID/OlHtn/dHlKWqN/ M8oyxZHJFJNvkVgZreTCV6DykDdmIibWnOE1HtPAUlEtPpTYYXr5BRJix0kQcRu5bv987MxxMwX 52wCwCGRwKRNpVxYZXk0x8zj/uie2X/1G0j2uWDAaNKE36huR7iwkmGYcqGdNkKAVGQ== X-Received: by 2002:a37:21e6:: with SMTP id f99-v6mr1117824qki.206.1529671931460; Fri, 22 Jun 2018 05:52:11 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdQQ78esT3TYDtFyobKPDnn5ZGwLAm7Fqlup5z19caSCINLuY29Bsz5HouxMjRodWCS0mEt X-Received: by 2002:a37:21e6:: with SMTP id f99-v6mr1117788qki.206.1529671930662; Fri, 22 Jun 2018 05:52:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529671930; cv=none; d=google.com; s=arc-20160816; b=kM9wu/GvkPd9hPtdLOydiR0r4HHFwI8IM1gBrfKpG58glYtVS8KW+GvKoN3nPP5F0h /n+w6q1IyMiN6yzdKEE3UqX4qvQhfvy1Y1hHqobqsMt89T4CwprDZ7lRaElY1iHyekiY JIzqN8cUgL88ONTRt1seGrG7ZmEahNEKCrcO/V1BNcqSpGWSAZTFeVFKwqrRC4ENjm4p FzpUOIYJz12VL1U6b7iwipiO0jH0hn4kSv9Aml9BcDrFp343HZ29B3I068Sm0Zb31dVe /K7OZs1vf+0g5gSX+zKPOy/mShWt5XDvEvUPa0uKmX6LBf4rOAlnRy9qxxaE9rdYUlbu Yhkg== 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=NjdL1QZQ8VObf+MLpsOx/tJP87w/vIzbdQicZaB92QA=; b=QFLJfB4oGXbYMWD+4jyIqL5NEPRepwtD+N4bVWk+qDoYP2+S5ZVG+fkdEKMOWzVwJp eb9aUcamqpgqywdZgkOc+YPUcvu6DEW+Tpi1DjEOW4/+Has17D9VcsbZa7h9hb0sX150 P8gZk++7IGWejOkMLs3FhYKFAj2IqeIVTZvppmUQSjkglNmIr+dSot3rNQEzVNZCTQ+4 VQM181P6a9uLpQRgSgGTNfjn4PBBhN5pXZ6CLV3aeFBkp0WuFdqS4fBp4SOIPAEB2RCA BM1IVkgEjUaVTEjWLBofy3Ux2GSMS+UWEylCSTYImWO7rQNhK0i1MM/lEZwBlHsCSMWU OeAA== 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 u1-v6si613024qka.174.2018.06.22.05.52.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jun 2018 05:52:10 -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-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 11466406C757; Fri, 22 Jun 2018 12:52:10 +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 F008F2026D6B; Fri, 22 Jun 2018 12:52:09 +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 w5MCq9Kh012494; Fri, 22 Jun 2018 08:52:09 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id w5MCq9aJ012490; Fri, 22 Jun 2018 08:52:09 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Fri, 22 Jun 2018 08:52:09 -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: <20180622090935.GT10465@dhcp22.suse.cz> Message-ID: References: <20180615073201.GB24039@dhcp22.suse.cz> <20180615115547.GH24039@dhcp22.suse.cz> <20180615130925.GI24039@dhcp22.suse.cz> <20180619104312.GD13685@dhcp22.suse.cz> <20180622090151.GS10465@dhcp22.suse.cz> <20180622090935.GT10465@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.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 22 Jun 2018 12:52:10 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 22 Jun 2018 12:52:10 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.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 Fri, 22 Jun 2018, Michal Hocko wrote: > On Fri 22-06-18 11:01:51, Michal Hocko wrote: > > On Thu 21-06-18 21:17:24, Mikulas Patocka wrote: > [...] > > > 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. > > > > Why? How are you going to audit all the callers that the behavior makes > > sense and moreover how are you going to ensure that future usage will > > still make sense. The more subtle side effects gfp flags have the harder > > they are to maintain. > > So just as an excercise. Try to explain the above semantic to users. We > currently have the following. > > * __GFP_NORETRY: The VM implementation will try only very lightweight > * memory direct reclaim to get some memory under memory pressure (thus > * it can sleep). It will avoid disruptive actions like OOM killer. The > * caller must handle the failure which is quite likely to happen under > * heavy memory pressure. The flag is suitable when failure can easily be > * handled at small cost, such as reduced throughput > > * __GFP_FS can call down to the low-level FS. Clearing the flag avoids the > * allocator recursing into the filesystem which might already be holding > * locks. > > So how are you going to explain gfp & (__GFP_NORETRY | ~__GFP_FS)? What > is the actual semantic without explaining the whole reclaim or force > users to look into the code to understand that? What about GFP_NOIO | > __GFP_NORETRY? What does it mean to that "should not sleep". Do all > shrinkers have to follow that as well? My reasoning was that there is broken code that uses __GFP_NORETRY and assumes that it can't fail - so conditioning the change on !__GFP_FS would minimize the diruption to the broken code. Anyway - if you want to test only on __GFP_NORETRY (and fix those 16 broken cases that assume that __GFP_NORETRY can't fail), I'm OK with that. Mikulas 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) && current_may_throttle() && pgdat_memcg_congested(pgdat, root)) wait_iff_congested(BLK_RW_ASYNC, HZ/10);