lkml.org 
[lkml]   [2005]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 12/12] mm: rmap opt
On Mon, 21 Nov 2005, Nick Piggin wrote:

> Optimise rmap functions by minimising atomic operations when
> we know there will be no concurrent modifications.

It's not quite right yet. A few minor points first:

You ought to convert the page_add_anon_rmap in fs/exec.c to
page_add_new_anon_rmap: that won't give a huge leap in performance,
but it will save someone coming along later and wondering why that
particular one isn't "new_".

The mod to page-flags.h at the end: nowhere is __SetPageReferenced
used, just cut the page-flags.h change out of your patch.

Perhaps that was at one time a half-way house to removing the
SetPageReferenced from do_anonymous_page: I support you in that
removal (I've several times argued that if it's needed there, then
it's also needed in several other like places which lack it; and I
think you concluded that it's just not needed); but you ought at least
to confess to that in the change comments, if it's not a separate patch.

I've spent longest staring at page_remove_rmap. Here's how it looks:

void page_remove_rmap(struct page *page)
{
int fast = (page_mapcount(page) == 1) &
PageAnon(page) & (!PageSwapCache(page));

/* fast page may become SwapCache here, but nothing new will map it. */
if (fast)
reset_page_mapcount(page);
else if (atomic_add_negative(-1, &page->_mapcount))
BUG_ON(page_mapcount(page) < 0);
if (page_test_and_clear_dirty(page))
set_page_dirty(page);
else
return; /* non zero mapcount */
/* [comment snipped for these purposes] */
__dec_page_state(nr_mapped);
}

Well, C doesn't yet allow indentation to take the place of braces:
I think you'll find your /proc/meminfo Mapped goes up and up, since
only on s390 will page_test_and_clear_dirty ever say yes.

That "fast" condition. I believe it's right, and I can see that in the
common case it will avoid the atomic -1. Yet it seems so desperate, and
is just begging for a hole to be found in the logic (I thought I'd found
one, but was forgetting I'd rearranged do_swap_page to remove from swap
cache when full _after_ its page_add_anon_rmap).

It also made me wonder whether barriers are needed between the different
tests: somehow I think not, but can't put into words how I think it is
protected. Were the "&"s instead of "&&"s a significant part of the
optimization, or an accident?

The page_remove_rmap part is rather ugly, but if going to those lengths
to avoid the atomic -1 is really a win on the majority of machines we
need to be fastest on (is that the case?), then okay.

Hugh
-
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/

\
 
 \ /
  Last update: 2005-11-22 20:23    [W:0.166 / U:33.068 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site