Re: [patch 12/12] mm: rmap opt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux