All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: jing xia <jing.xia.mail@gmail.com>,
	Mike Snitzer <snitzer@redhat.com>,
	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
Date: Fri, 22 Jun 2018 08:52:09 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LRH.2.02.1806220845190.8072@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <20180622090935.GT10465@dhcp22.suse.cz>



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);
 

  reply	other threads:[~2018-06-22 12:52 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-12  8:03 [PATCH] dm bufio: Reduce dm_bufio_lock contention Jing Xia
2018-06-12 21:20 ` Mike Snitzer
2018-06-13 14:02   ` Mikulas Patocka
2018-06-14  7:18     ` jing xia
2018-06-14  7:31       ` Michal Hocko
2018-06-14 18:34         ` Mikulas Patocka
2018-06-15  7:32           ` Michal Hocko
2018-06-15 11:35             ` Mikulas Patocka
2018-06-15 11:55               ` Michal Hocko
2018-06-15 12:47                 ` Mikulas Patocka
2018-06-15 13:09                   ` Michal Hocko
2018-06-18 22:11                     ` Mikulas Patocka
2018-06-18 22:11                       ` Mikulas Patocka
2018-06-19 10:43                       ` Michal Hocko
2018-06-22  1:17                         ` Mikulas Patocka
2018-06-22  9:01                           ` Michal Hocko
2018-06-22  9:09                             ` Michal Hocko
2018-06-22 12:52                               ` Mikulas Patocka [this message]
2018-06-22 13:05                                 ` Michal Hocko
2018-06-22 18:57                                   ` Mikulas Patocka
2018-06-25  9:09                                     ` Michal Hocko
2018-06-25 13:53                                       ` Mikulas Patocka
2018-06-25 13:53                                         ` Mikulas Patocka
2018-06-25 14:14                                         ` Michal Hocko
2018-06-25 14:42                                           ` Mikulas Patocka
2018-06-25 14:42                                             ` Mikulas Patocka
2018-06-25 14:57                                             ` Michal Hocko
2018-06-29  2:43                                               ` Mikulas Patocka
2018-06-29  2:43                                                 ` Mikulas Patocka
2018-06-29  8:29                                                 ` Michal Hocko
2018-06-22 12:44                             ` Mikulas Patocka
2018-06-22 13:10                               ` Michal Hocko
2018-06-22 18:46                                 ` Mikulas Patocka
2018-08-01  2:48         ` jing xia
2018-08-01  7:03           ` Michal Hocko
2018-09-03 22:23           ` Mikulas Patocka
2018-09-04  7:08             ` Michal Hocko
2018-09-04 15:18               ` Mike Snitzer
2018-09-04 16:08                 ` Michal Hocko
2018-09-04 17:30                   ` Mikulas Patocka
2018-09-04 17:30                     ` Mikulas Patocka
2018-09-04 17:45                     ` Michal Hocko
2018-09-04 17:45                       ` Michal Hocko
2018-06-14  7:16   ` jing xia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LRH.2.02.1806220845190.8072@file01.intranet.prod.int.rdu2.redhat.com \
    --to=mpatocka@redhat.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=jing.xia.mail@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=snitzer@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.