linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>,
	Martin Michlmayr <tbm@cyrius.com>,
	linux-mips@linux-mips.org, linux-ext4@vger.kernel.org
Subject: Re: ext4dev build failure on mips: "empty_zero_page" undefined
Date: Thu, 15 May 2008 09:39:04 -0400	[thread overview]
Message-ID: <20080515133904.GE18825@mit.edu> (raw)
In-Reply-To: <20080513051252.GA20575@linux-mips.org>

On Tue, May 13, 2008 at 06:12:52AM +0100, Ralf Baechle wrote:
> The ZERO_PAGE(0) call in ext4_ext_zeroout is the culprit.  Using a zero
> argument allows the compiler to eleminate the reference to zero_page_mask.
> 
> Am I reading this right that ZERO_PAGE() is being used without any
> mappings to userspace being involved?

Correct.  Ext4 supports unitialized extents; this is useful in DVR's,
for example, where there is a desire to allocate contiguous blocks
for, say, a 60 minute TV show, without having to pay the cost of
zero'ing the blocks.  But in some cases where someone seeks a few
blocks ahead, and writes into the middle of the unitialized region,
instead of splitting the unitialized extent into 3 pieces, for short
regions we will simply zero out a few blocks and then write the
requested block.  

This is better in the case of binutils, for example, where it will
write out blocks in a random order using a few close-range seeks, and
it's more efficient to do this than to bloat out the extent tree only
to have to recombine extents later.

Anyway, yes, we just need to use the zero page without any user
mapping being involved.

						- Ted

  reply	other threads:[~2008-05-15 13:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-12 13:06 ext4dev build failure on mips: "empty_zero_page" undefined Martin Michlmayr
2008-05-12 13:54 ` Dmitri Vorobiev
2008-05-12 14:34   ` Theodore Tso
2008-05-12 14:46     ` Dmitri Vorobiev
2008-05-13  4:50       ` Ralf Baechle
2008-05-13  5:12         ` Ralf Baechle
2008-05-15 13:39           ` Theodore Tso [this message]
2008-05-28  7:06         ` Martin Michlmayr
2008-06-05 11:11           ` Martin Michlmayr
2008-06-05 11:22             ` Dmitri Vorobiev
2008-06-05 18:38               ` Theodore Tso
2008-06-05 21:34                 ` Vorobiev Dmitri
2008-06-05 21:51                   ` Thiemo Seufer
2008-06-06  6:57                     ` Dmitri Vorobiev
2008-06-06 13:15                     ` Theodore Tso
2008-05-12 14:58     ` Martin Michlmayr
2008-05-12 15:14       ` Dmitri Vorobiev
2008-05-12 17:35         ` Theodore Tso
2008-05-12 19:37           ` Dmitri Vorobiev
2008-05-13  0:55             ` Stephen Rothwell
2008-05-13  1:42               ` Stephen Rothwell
2008-05-13  4:23                 ` Ralf Baechle

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=20080515133904.GE18825@mit.edu \
    --to=tytso@mit.edu \
    --cc=dmitri.vorobiev@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=tbm@cyrius.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).