Hi,
during my page_mkwrite() work, I've looked at who uses nobh_ versions of
various functions in fs/buffer.c. It seems only ext2 and jfs use them. ext3
uses them only from writepage() (which means we needn't attach buffers to a
page when it was written via mmap in writeback mode) and ext4 tries to use
them but in fact it's nop because it always attaches buffers to the page
earlier. So it's not really widely used, there's quite some code to support
it (including one page flag), and it also slightly complicates my
page_mkwrite() fixes.
So I wanted to ask does somebody actually remember what it is good for?
Buffer heads obviously consume some memory so was that the reason? OTOH we
have to map the page whenever we write to it or send it to disk via
writepage().
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
On 09/17/2009 04:56 PM, Jan Kara wrote:
> Hi,
>
> during my page_mkwrite() work, I've looked at who uses nobh_ versions of
> various functions in fs/buffer.c. It seems only ext2 and jfs use them. ext3
> uses them only from writepage() (which means we needn't attach buffers to a
> page when it was written via mmap in writeback mode) and ext4 tries to use
> them but in fact it's nop because it always attaches buffers to the page
> earlier. So it's not really widely used, there's quite some code to support
> it (including one page flag), and it also slightly complicates my
> page_mkwrite() fixes.
> So I wanted to ask does somebody actually remember what it is good for?
> Buffer heads obviously consume some memory so was that the reason? OTOH we
> have to map the page whenever we write to it or send it to disk via
> writepage().
>
> Honza
I'm currently using nobh_truncate_page() in fs/exofs/inode.c::exofs_truncate().
Though, I suspect that once I do the conversion to Nick's:
"[patch 00/11] new truncate sequence"
and it is submitted, that use will disappear.
Thanks
Boaz
On Thu 17-09-09 18:11:27, Boaz Harrosh wrote:
> On 09/17/2009 04:56 PM, Jan Kara wrote:
> > Hi,
> >
> > during my page_mkwrite() work, I've looked at who uses nobh_ versions of
> > various functions in fs/buffer.c. It seems only ext2 and jfs use them. ext3
> > uses them only from writepage() (which means we needn't attach buffers to a
> > page when it was written via mmap in writeback mode) and ext4 tries to use
> > them but in fact it's nop because it always attaches buffers to the page
> > earlier. So it's not really widely used, there's quite some code to support
> > it (including one page flag), and it also slightly complicates my
> > page_mkwrite() fixes.
> > So I wanted to ask does somebody actually remember what it is good for?
> > Buffer heads obviously consume some memory so was that the reason? OTOH we
> > have to map the page whenever we write to it or send it to disk via
> > writepage().
> >
> > Honza
>
> I'm currently using nobh_truncate_page() in fs/exofs/inode.c::exofs_truncate().
>
> Though, I suspect that once I do the conversion to Nick's:
> "[patch 00/11] new truncate sequence"
> and it is submitted, that use will disappear.
Yeah, actually with page_mkwrite patches I've just sent, this would
definitely go away so this isn't a use I'm too much worried about ;). But
thanks for info anyway.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
Jan Kara wrote:
> Hi,
>
> during my page_mkwrite() work, I've looked at who uses nobh_ versions of
> various functions in fs/buffer.c. It seems only ext2 and jfs use them. ext3
> uses them only from writepage() (which means we needn't attach buffers to a
> page when it was written via mmap in writeback mode) and ext4 tries to use
> them but in fact it's nop because it always attaches buffers to the page
> earlier. So it's not really widely used, there's quite some code to support
> it (including one page flag), and it also slightly complicates my
> page_mkwrite() fixes.
> So I wanted to ask does somebody actually remember what it is good for?
> Buffer heads obviously consume some memory so was that the reason? OTOH we
> have to map the page whenever we write to it or send it to disk via
> writepage().
>
>
Originally it was supported on ext2. I added support nobh support for
ext3. At that time, the main
issue/complaint was that, these bufferheads consume memory from
ZONE_NORMAL causing
memory pressure on 32-bit (i386) configurations.
Thanks,
Badari
On Thu, Sep 17, 2009 at 09:21:37PM -0700, Badari Pulavarty wrote:
>
> Originally it was supported on ext2. I added support nobh support for
> ext3. At that time, the main
> issue/complaint was that, these bufferheads consume memory from
> ZONE_NORMAL causing
> memory pressure on 32-bit (i386) configurations.
Specifically, it matters on very large configuration systems (i.e.,
32GB-64GB using PAE-36) that today we'd probably just say, "use
x86_64, you moron". It would probably matter if someone were to want
to upgrade a non-64-bit capable machine to a newer kernel.
Dropping nobh from ext3 at this point might prevent some of these
older systems from upgrading, I'm not sure how much we would care; on
the one hand, these machines tended to be pretty expensive, so people
would probably want to use them for a while. On the other hand, it
has been over five years now since x86_64 machines have been
available, and many of these customers are highly unlikely to want to
upgrade anyway.
- Ted
On Fri, 18 Sep 2009 10:12:26 -0400
Theodore Tso <[email protected]> wrote:
> On Thu, Sep 17, 2009 at 09:21:37PM -0700, Badari Pulavarty wrote:
> >
> > Originally it was supported on ext2. I added support nobh support
> > for ext3. At that time, the main
> > issue/complaint was that, these bufferheads consume memory from
> > ZONE_NORMAL causing
> > memory pressure on 32-bit (i386) configurations.
>
> Specifically, it matters on very large configuration systems (i.e.,
> 32GB-64GB using PAE-36) that today we'd probably just say, "use
> x86_64, you moron". It would probably matter if someone were to want
> to upgrade a non-64-bit capable machine to a newer kernel.
>
> Dropping nobh from ext3 at this point might prevent some of these
> older systems from upgrading, I'm not sure how much we would care; on
> the one hand, these machines tended to be pretty expensive, so people
> would probably want to use them for a while. On the other hand, it
> has been over five years now since x86_64 machines have been
> available, and many of these customers are highly unlikely to want to
> upgrade anyway.
isn't the converse to just make nobh the default but not an option a
better approach then?
I forgot why this was a good idea to be an option again ;-)
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Fri 18-09-09 16:25:54, Arjan van de Ven wrote:
> On Fri, 18 Sep 2009 10:12:26 -0400
> Theodore Tso <[email protected]> wrote:
> > On Thu, Sep 17, 2009 at 09:21:37PM -0700, Badari Pulavarty wrote:
> > >
> > > Originally it was supported on ext2. I added support nobh support
> > > for ext3. At that time, the main
> > > issue/complaint was that, these bufferheads consume memory from
> > > ZONE_NORMAL causing
> > > memory pressure on 32-bit (i386) configurations.
> >
> > Specifically, it matters on very large configuration systems (i.e.,
> > 32GB-64GB using PAE-36) that today we'd probably just say, "use
> > x86_64, you moron". It would probably matter if someone were to want
> > to upgrade a non-64-bit capable machine to a newer kernel.
> >
> > Dropping nobh from ext3 at this point might prevent some of these
> > older systems from upgrading, I'm not sure how much we would care; on
> > the one hand, these machines tended to be pretty expensive, so people
> > would probably want to use them for a while. On the other hand, it
> > has been over five years now since x86_64 machines have been
> > available, and many of these customers are highly unlikely to want to
> > upgrade anyway.
>
> isn't the converse to just make nobh the default but not an option a
> better approach then?
> I forgot why this was a good idea to be an option again ;-)
Buffer heads cache useful information so without them, IO may become more
more CPU intensive (allocating and freeing temporary buffer heads, setting
up block mapping etc.).
Also some features like delayed allocation need buffer head bits - that
is why e.g. ext4 doesn't really support nobh mount option.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
On Thu, Sep 17, 2009 at 09:21:37PM -0700, Badari Pulavarty wrote:
> Originally it was supported on ext2. I added support nobh support for
> ext3. At that time, the main
> issue/complaint was that, these bufferheads consume memory from
> ZONE_NORMAL causing
> memory pressure on 32-bit (i386) configurations.
Yeah, I think that's a tradeof past it's days. I'm all for nuking it,
and while we're at it we should also find a better way to integrate the
mpage bits. Not using them is pretty dumb, so the default aops should
really be mpage if possible, else fall back without the need for
different sets of aops.