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
Hugh Dickins wrote:
> 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:
>

Thanks for looking at it.

> 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_".
>

Yep, you mentioned that before but I must have lost the hunk.

> 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.
>

You're right. I'll split that and fix the page-flags.h.

> 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.
>

Thanks. It is fairly obscure, and possibly has memory ordering problems.
Also the conditional jumps and icache usage are increased, so it isn't
as clear a win as the add_new_anon_rmap's. I'll drop this part for the
moment.

Nick

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com

-
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-23 00:08    [W:1.695 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site