[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090217143506.f6899342.akpm@linux-foundation.org>
Date: Tue, 17 Feb 2009 14:35:06 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Edward Shishkin <edward.shishkin@...il.com>
Cc: peterz@...radead.org, edward.shishkin@...il.com, npiggin@...e.de,
rmh3093@...il.com, randy.dunlap@...cle.com,
linux-kernel@...r.kernel.org, reiserfs-devel@...r.kernel.org
Subject: Re: [patch 2/4] vfs: add set_page_dirty_notag
On Tue, 17 Feb 2009 01:43:28 +0300
Edward Shishkin <edward.shishkin@...il.com> wrote:
> + */
> +int set_page_dirty_notag(struct page *page)
> +{
> + struct address_space *mapping = page->mapping;
> +
> + if (!TestSetPageDirty(page)) {
> + WARN_ON_ONCE(!PagePrivate(page) && !PageUptodate(page));
> + if (mapping_cap_account_dirty(mapping)) {
> + /*
> + * The accounting functions rely on
> + * being atomic wrt interrupts.
> + */
> + unsigned long flags;
> + local_irq_save(flags);
> + __inc_zone_page_state(page, NR_FILE_DIRTY);
> + __inc_bdi_stat(mapping->backing_dev_info,
> + BDI_RECLAIMABLE);
> + task_dirty_inc(current);
> + task_io_account_write(PAGE_CACHE_SIZE);
> + local_irq_restore(flags);
> + }
> + __mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
> + return 1;
> + }
> + return 0;
> +}
I'll maintain this in -mm, alongside the resier4 patches which need it.
Of course, this rather obviates the purpose - if someone changes, say,
__set_page_dirty_nobuffers() then they won't similarly update
set_page_dirty_notag(). Oh well.
This problem would fix itself if those two functions were to
substantially share code. And I think we can do that - something like
static void
update_page_accounting(struct page *page, struct address_space *mapping)
{
__inc_zone_page_state(page, NR_FILE_DIRTY);
__inc_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE);
task_dirty_inc(current);
task_io_account_write(PAGE_CACHE_SIZE);
}
maybe?
We could do that as a separate patch and merge it into mainline - it
should have zero impact on code generation if gcc does the right thing
(please check this).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists