Messages in this thread | | | From | Blaisorblade <> | Subject | Re: [uml-devel] Re: VFS interactions with UML and other big UML changes (was: Re: [patch 1/2] Uml - first part rework of run_helper() and users.) | Date | Wed, 1 Dec 2004 01:51:35 +0100 |
| |
On Wednesday 01 December 2004 01:33, Andrew Morton wrote: > Blaisorblade <blaisorblade_spam@yahoo.it> wrote: > > static struct address_space_operations hostfs_aops = { > > .writepage = hostfs_writepage, > > .readpage = hostfs_readpage, > > /* .set_page_dirty = __set_page_dirty_nobuffers, */ > > .prepare_write = hostfs_prepare_write, > > .commit_write = hostfs_commit_write > > }; > > > > Actually, hostfs is a nodev filesystem, but I simply don't know if that > > implies that it uses no buffers. So, should > > > > .set_page_dirty = __set_page_dirty_nobuffers > > > > be uncommented? Or should it be deleted (leaving it there is not a good > > option). > > See the operation of set_page_dirty().
> If you have NULL ->set_page_dirty a_op then set_page_dirty() will fall > through to __set_page_dirty_buffers(). Yes, I already understood this, the easy part. > If your fs never sets PG_private then __set_page_dirty_buffers() will just > do what __set_page_dirty_nobuffers() does. Ok, I didn't imagine this (looks reasonable though).
Apart the fact that the "race with truncate" check is a bit different: this is is in __set_page_dirty_nobuffers(mm/page-writeback.c) and probably wants being added to the _buffers version, since it does cannot do anything else than triggering a BUG (which you don't see currently, I guess):
[...] mapping2 = page_mapping(page); if (mapping2) { /* Race with truncate? */ BUG_ON(mapping2 != mapping); [...]
> Without having looked at it, I'm sure that hostfs does not use > buffer_heads.
It can compile without
#include <linux/buffer_head.h>
(even if the include is there), and it never seem to set any page as buffer (by setting the PG_private bit, which can have other meanings too I guess in other contexts).
So I guessed this right the first time - I was not sure if it was so straightforward.
> So setting your ->set_page_dirty a_op to point at > __set_page_dirty_nobuffers() is a reasonable thing to do - it'll provide a > slight speedup.
If it is a speedup only, then I'm happier - I was especially worried if it was going to create possible bugs, even because there are someone has reported problems in listing large folders... never reproduced it here and most users don't see it, so not yet any clues.
Thanks a lot for the help! -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |