All of lore.kernel.org
 help / color / mirror / Atom feed
From: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
To: Theodore Tso <tytso@MIT.EDU>
Cc: toshi.okajima@jp.fujitsu.com, akpm@linux-foundation.org,
	viro@zeniv.linux.org.uk, sct@redhat.com, adilger@sun.com,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RESEND][PATCH 2/3 BUG,RFC] ext3: release block-device-mapping buffer_heads which have the filesystem private data for avoiding	oom-killer
Date: Tue, 25 Nov 2008 13:09:12 +0900	[thread overview]
Message-ID: <492B7A68.7060304@jp.fujitsu.com> (raw)
In-Reply-To: <492B4E48.3080000@jp.fujitsu.com>

Hi Ted,
I have reconsidered your comments.

Toshiyuki Okajima wrote:
> Hi Ted,
> Thanks for your comments.
> 
>  > Hi Toshijuki,
<SNIP>
>  > Your patch series looks good, but I have one comment, for the ext3 and
>  > ext4 patches:
>  >
>  > > +    if (journal != NULL)
>  > > +        return journal_try_to_free_buffers(journal, page, wait);
>  > > +    else
>  > > +        return try_to_free_buffers(page);
>  >
>  > According to the documentation for journal_try_to_free_buffers():
>  >
>  >  * This function returns non-zero if we wish try_to_free_buffers()
>  >  * to be called. We do this if the page is releasable by 
> try_to_free_buffers().
>  >  * We also do it if the page has locked or dirty buffers and the 
> caller wants
>  >  * us to perform sync or async writeout.
> I forgot reading it.
I think this document is obsolete because a current version of
journal_try_to_free_buffers() also calls try_to_free_buffers().
So, this document needs to be changed.
Therefore I don't need to change my patch, OK?

[current version]
1727 int journal_try_to_free_buffers(journal_t *journal,
1728                                 struct page *page, gfp_t gfp_mask)
1729 {
1730         struct buffer_head *head;
1731         struct buffer_head *bh;
1732         int ret = 0;
1733
1734         J_ASSERT(PageLocked(page));
1735
1736         head = page_buffers(page);
1737         bh = head;
1738         do {
1739                 struct journal_head *jh;
1740
1741                 /*
1742                  * We take our own ref against the journal_head here to avoid
1743                  * having to add tons of locking around each instance of
1744                  * journal_remove_journal_head() and journal_put_journal_head().
1745                  */
1746                 jh = journal_grab_journal_head(bh);
1747                 if (!jh)
1748                         continue;
1749
1750                 jbd_lock_bh_state(bh);
1751                 __journal_try_to_free_buffer(journal, bh);
1752                 journal_put_journal_head(jh);
1753                 jbd_unlock_bh_state(bh);
1754                 if (buffer_jbd(bh))
1755                         goto busy;
1756         } while ((bh = bh->b_this_page) != head);
1757
1758         ret = try_to_free_buffers(page);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1759
1760         /*
1761          * There are a number of places where journal_try_to_free_buffers()
1762          * could race with journal_commit_transaction(), the later still
1763          * holds the reference to the buffers to free while processing them.
1764          * try_to_free_buffers() failed to free those buffers. Some of the
1765          * caller of releasepage() request page buffers to be dropped, otherwise
1766          * treat the fail-to-free as errors (such as generic_file_direct_IO())
1767          *
1768          * So, if the caller of try_to_release_page() wants the synchronous
1769          * behaviour(i.e make sure buffers are dropped upon return),
1770          * let's wait for the current transaction to finish flush of
1771          * dirty data buffers, then try to free those buffers again,
1772          * with the journal locked.
1773          */
1774         if (ret == 0 && (gfp_mask & __GFP_WAIT) && (gfp_mask & __GFP_FS)) {
1775                 journal_wait_for_transaction_sync_data(journal);
1776                 ret = try_to_free_buffers(page);
1777         }
1778
1779 busy:
1780         return ret;
1781 }

[old version(linux-2.4.36.8)]
   1731	int journal_try_to_free_buffers(journal_t *journal,
   1732					struct page *page, int gfp_mask)
   1733	{
...
   1759		struct buffer_head *bh;
   1760		struct buffer_head *tmp;
   1761		int locked_or_dirty = 0;
   1762		int call_ttfb = 1;
   1763	
   1764		J_ASSERT(PageLocked(page));
   1765	
   1766		bh = page->buffers;
   1767		tmp = bh;
   1768		spin_lock(&journal_datalist_lock);
   1769		do {
   1770			struct buffer_head *p = tmp;
   1771	
   1772			if (unlikely(!tmp)) {
   1773				debug_page(page);
   1774				BUG();
   1775			}
   1776				
   1777			tmp = tmp->b_this_page;
   1778			if (buffer_jbd(p))
   1779				if (!__journal_try_to_free_buffer(p, &locked_or_dirty))
   1780					call_ttfb = 0;
   1781		} while (tmp != bh);
   1782		spin_unlock(&journal_datalist_lock);
   1783	
   1784		if (!(gfp_mask & (__GFP_IO|__GFP_WAIT)))
   1785			goto out;
   1786		if (!locked_or_dirty)
   1787			goto out;
   1788		/*
   1789		 * The VM wants us to do writeout, or to block on IO, or both.
   1790		 * So we allow try_to_free_buffers to be called even if the page
   1791		 * still has journalled buffers.
   1792		 */
   1793		call_ttfb = 1;
   1794	out:
   1795		return call_ttfb;
   1796	}

Regards,
Toshiyuki Okajima


      reply	other threads:[~2008-11-25  4:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-20  0:34 [RESEND][PATCH 2/3 BUG,RFC] ext3: release block-device-mapping buffer_heads which have the filesystem private data for avoiding oom-killer Toshiyuki Okajima
2008-11-24  5:51 ` Theodore Tso
2008-11-25  1:00   ` Toshiyuki Okajima
2008-11-25  4:09     ` Toshiyuki Okajima [this message]

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=492B7A68.7060304@jp.fujitsu.com \
    --to=toshi.okajima@jp.fujitsu.com \
    --cc=adilger@sun.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sct@redhat.com \
    --cc=tytso@MIT.EDU \
    --cc=viro@zeniv.linux.org.uk \
    /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.