[PATCH] jbd2: get rid of open coded allocation retry loop

[PATCH] jbd2: get rid of open coded allocation retry loop

[Michal Hocko]

insert_revoke_hash does an open coded endless allocation loop if
journal_oom_retry is true. It doesn't implement any allocation fallback
strategy between the retries, though. The memory allocator doesn't know
about the never fail requirement so it cannot potentially help to move
on with the allocation (e.g. use memory reserves).

Get rid of the retry loop and use __GFP_NOFAIL instead. We will lose the
debugging message but I am not sure it is anyhow helpful.

Do the same for journal_alloc_journal_head which is doing a similar
thing.

Signed-off-by: Michal Hocko <mhocko@suse.cz>
---

Hi,
While looking at something unrelated I have encountered the following
two open coded endless loops around allocation request. I have converted
them to use __GFP_NOFAIL in lines of http://marc.info/?l=linux-mm&m=143377014630186&w=2.

journal_oom_retry is hardcoded to 1 and used only at a single place in
jbd2 code so I guess it is just a left over. Nevertheless, I have kept
it there because I do not understand its historical purpose. Anyway
it seems like removing it would allow some more clean ups because
insert_revoke_hash doesn't have any other failure modes (same applies to
jbd2_journal_set_revoke). Let me know if you would be interested in
such a cleanup.

Thanks!

 fs/jbd2/journal.c |  6 ++----
 fs/jbd2/revoke.c  | 15 +++++----------
 2 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index b96bd8076b70..218414703f11 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -2362,10 +2362,8 @@ static struct journal_head *journal_alloc_journal_head(void)
 	if (!ret) {
 		jbd_debug(1, "out of memory for journal_head\n");
 		pr_notice_ratelimited("ENOMEM in %s, retrying.\n", __func__);
-		while (!ret) {
-			yield();
-			ret = kmem_cache_zalloc(jbd2_journal_head_cache, GFP_NOFS);
-		}
+		ret = kmem_cache_zalloc(jbd2_journal_head_cache,
+				GFP_NOFS | __GFP_NOFAIL);
 	}
 	return ret;
 }
diff --git a/fs/jbd2/revoke.c b/fs/jbd2/revoke.c
index c6cbaef2bda1..f9eb93e1b3cb 100644
--- a/fs/jbd2/revoke.c
+++ b/fs/jbd2/revoke.c
@@ -141,11 +141,13 @@ static int insert_revoke_hash(journal_t *journal, unsigned long long blocknr,
 {
 	struct list_head *hash_list;
 	struct jbd2_revoke_record_s *record;
+	gfp_t gfp_mask = GFP_NOFS;
 
-repeat:
-	record = kmem_cache_alloc(jbd2_revoke_record_cache, GFP_NOFS);
+	if (journal_oom_retry)
+		gfp_mask |= __GFP_NOFAIL;
+	record = kmem_cache_alloc(jbd2_revoke_record_cache, gfp_mask);
 	if (!record)
-		goto oom;
+		return -ENOMEM;
 
 	record->sequence = seq;
 	record->blocknr = blocknr;
@@ -154,13 +156,6 @@ static int insert_revoke_hash(journal_t *journal, unsigned long long blocknr,
 	list_add(&record->hash, hash_list);
 	spin_unlock(&journal->j_revoke_lock);
 	return 0;
-
-oom:
-	if (!journal_oom_retry)
-		return -ENOMEM;
-	jbd_debug(1, "ENOMEM in %s, retrying\n", __func__);
-	yield();
-	goto repeat;
 }
 
 /* Find a revoke record in the journal's hash table. */
-- 
2.1.4

Re: [PATCH] jbd2: get rid of open coded allocation retry loop

[Theodore Ts'o]

On Mon, Jun 15, 2015 at 04:17:34PM +0200, Michal Hocko wrote:
> insert_revoke_hash does an open coded endless allocation loop if
> journal_oom_retry is true. It doesn't implement any allocation fallback
> strategy between the retries, though. The memory allocator doesn't know
> about the never fail requirement so it cannot potentially help to move
> on with the allocation (e.g. use memory reserves).
> 
> Get rid of the retry loop and use __GFP_NOFAIL instead. We will lose the
> debugging message but I am not sure it is anyhow helpful.
> 
> Do the same for journal_alloc_journal_head which is doing a similar
> thing.
> 
> Signed-off-by: Michal Hocko <mhocko@suse.cz>

Thanks, applied.

					- Ted

Re: [PATCH] jbd2: get rid of open coded allocation retry loop

[Michal Hocko]

On Mon 15-06-15 15:47:04, Theodore Ts'o wrote:
> On Mon, Jun 15, 2015 at 04:17:34PM +0200, Michal Hocko wrote:
> > insert_revoke_hash does an open coded endless allocation loop if
> > journal_oom_retry is true. It doesn't implement any allocation fallback
> > strategy between the retries, though. The memory allocator doesn't know
> > about the never fail requirement so it cannot potentially help to move
> > on with the allocation (e.g. use memory reserves).
> > 
> > Get rid of the retry loop and use __GFP_NOFAIL instead. We will lose the
> > debugging message but I am not sure it is anyhow helpful.
> > 
> > Do the same for journal_alloc_journal_head which is doing a similar
> > thing.
> > 
> > Signed-off-by: Michal Hocko <mhocko@suse.cz>
> 
> Thanks, applied.

Thanks!
-- 
Michal Hocko
SUSE Labs