All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
To: Linux Kernel ML <linux-kernel@vger.kernel.org>
Cc: linux-mm <linux-mm@kvack.org>,
	LHMS <lhms-devel@lists.sourceforge.net>,
	Andrew Morton <akpm@osdl.org>,
	William Lee Irwin III <wli@holomorphy.com>,
	Dave Hansen <haveblue@us.ibm.com>,
	Hirokazu Takahashi <taka@valinux.co.jp>
Subject: [RFC][PATCH] no bitmap buddy allocator : removing atomic ops (4/4)
Date: Wed, 08 Sep 2004 21:08:43 +0900	[thread overview]
Message-ID: <413EF64B.2060407@jp.fujitsu.com> (raw)


This part is part (4/4) and replaces atomic ops with non-atomic ops.
This micro optimization can improve the performance of the no-bitmap
buddy system.

To check effects of this patch. I made a tiny test.

************** test-program ********************
for(i = 0; i < 1000; i++) {
	mmap(16 Mega bytes, MAP_ANON);
	touch all pages;
	munmap(16 Mega bytes);
}
************************************************
Results of this program.
Host : Intex Xeon 1.8GHz x2, Memory 8Gbytes. Multi-user mode.

Reference Kernel --- linux-2.6.9-rc1-mm4
Total 0:35.79 System 33.89 User 1.88
Total 0:35.44 System 33.58 User 1.85
Total 0:35.75 System 33.81 User 1.91
Total 0:35.89 System 34.03 User 1.82
Total 0:35.93 System 34.03 User 1.84

No-bitmap without this micro-optimization patch
Total 0:37.58 System 35.69 User 1.89
Total 0:37.52 System 35.66 User 1.86
Total 0:37.56 System 35.68 User 1.88
Total 0:37.64 System 35.76 User 1.88
Total 0:37.72 System 35.89 User 1.82

No-bitmap with this micro-optimization patch.
Total 0:35.28 System 33.45 User 1.81
Total 0:35.38 System 33.62 User 1.75
Total 0:35.44 System 33.58 User 1.84
Total 0:35.52 System 33.58 User 1.90
Total 0:35.79 System 33.92 User 1.81

Single-user-mode.

reference-kernel  linux-2.6.9-rc1-mm4:
Total 0:35.20 System 33.32 User 1.88
Total 0:35.23 System 33.37 User 1.85
Total 0:35.58 System 33.77 User 1.81
Total 0:35.49 System 33.60 User 1.90
Total 0:35.79 System 33.80 User 1.99

No-bitmap without this micro-optimization patch
Total 0:36.83 System 35.16 User 1.67
Total 0:36.45 System 34.66 User 1.79
Total 0:36.81 System 35.10 User 1.70
Total 0:36.89 System 35.24 User 1.65
Total 0:36.82 System 35.14 User 1.68

No-bitmap with this micor-optimization patch:
Total 0:34.97 System 33.07 User 1.89
Total 0:34.94 System 32.98 User 1.95
Total 0:34.99 System 33.11 User 1.87
Total 0:34.90 System 33.14 User 1.76
Total 0:34.92 System 33.02 User 1.90


Results with this patch is better than ones without this by 2 seconds.
2/1000 = 2ms per 1 iteration (for 16 Megabytes alloc/free).

Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

---

  test-kernel-kamezawa/include/linux/page-flags.h |    2 ++
  test-kernel-kamezawa/mm/page_alloc.c            |    8 ++++----
  2 files changed, 6 insertions(+), 4 deletions(-)

diff -puN include/linux/page-flags.h~eliminate-bitmap-opt include/linux/page-flags.h
--- test-kernel/include/linux/page-flags.h~eliminate-bitmap-opt	2004-09-08 18:48:43.115922392 +0900
+++ test-kernel-kamezawa/include/linux/page-flags.h	2004-09-08 18:48:43.120921632 +0900
@@ -239,6 +239,8 @@ extern unsigned long __read_page_state(u
  #define SetPagePrivate(page)	set_bit(PG_private, &(page)->flags)
  #define ClearPagePrivate(page)	clear_bit(PG_private, &(page)->flags)
  #define PagePrivate(page)	test_bit(PG_private, &(page)->flags)
+#define __SetPagePrivate(page)  __set_bit(PG_private, &(page)->flags)
+#define __ClearPagePrivate(page) __clear_bit(PG_private, &(page)->flags)

  #define PageWriteback(page)	test_bit(PG_writeback, &(page)->flags)
  #define SetPageWriteback(page)						\
diff -puN mm/page_alloc.c~eliminate-bitmap-opt mm/page_alloc.c
--- test-kernel/mm/page_alloc.c~eliminate-bitmap-opt	2004-09-08 18:48:43.118921936 +0900
+++ test-kernel-kamezawa/mm/page_alloc.c	2004-09-08 18:48:43.123921176 +0900
@@ -242,11 +242,11 @@ static inline void __free_pages_bulk (st
  		page_idx &= buddy_idx;
  		list_del(&buddy->lru);
  		/* for propriety of PG_private bit, we clear it */
-		ClearPagePrivate(buddy);
+		__ClearPagePrivate(buddy);
  	}
  	/* record the final order of the page */
  	coalesced_page = base + page_idx;
-	SetPagePrivate(coalesced_page);
+	__SetPagePrivate(coalesced_page);
  	set_page_order(coalesced_page,order);
  	list_add(&coalesced_page->lru, &zone->free_area[order].free_list);
  }
@@ -347,7 +347,7 @@ expand(struct zone *zone, struct page *p
  		list_add(&page[size].lru, &area->free_list);
  		/* Note: already have lock, we don't need to use atomic ops */
  		set_page_order(&page[size], high);
-		SetPagePrivate(&page[size]);
+		__SetPagePrivate(&page[size]);
  	}
  	return page;
  }
@@ -410,7 +410,7 @@ static struct page *__rmqueue(struct zon
  		page = list_entry(area->free_list.next, struct page, lru);
  		list_del(&page->lru);
  		/* Note: already have lock, we don't need to use atomic ops */
-		ClearPagePrivate(page);
+		__ClearPagePrivate(page);
  		zone->free_pages -= 1UL << order;
  		return expand(zone, page, order, current_order, area);
  	}

_


WARNING: multiple messages have this Message-ID (diff)
From: Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
To: Linux Kernel ML <linux-kernel@vger.kernel.org>
Cc: linux-mm <linux-mm@kvack.org>,
	LHMS <lhms-devel@lists.sourceforge.net>,
	Andrew Morton <akpm@osdl.org>,
	William Lee Irwin III <wli@holomorphy.com>,
	Dave Hansen <haveblue@us.ibm.com>,
	Hirokazu Takahashi <taka@valinux.co.jp>
Subject: [RFC][PATCH] no bitmap buddy allocator : removing atomic ops (4/4)
Date: Wed, 08 Sep 2004 21:08:43 +0900	[thread overview]
Message-ID: <413EF64B.2060407@jp.fujitsu.com> (raw)

This part is part (4/4) and replaces atomic ops with non-atomic ops.
This micro optimization can improve the performance of the no-bitmap
buddy system.

To check effects of this patch. I made a tiny test.

************** test-program ********************
for(i = 0; i < 1000; i++) {
	mmap(16 Mega bytes, MAP_ANON);
	touch all pages;
	munmap(16 Mega bytes);
}
************************************************
Results of this program.
Host : Intex Xeon 1.8GHz x2, Memory 8Gbytes. Multi-user mode.

Reference Kernel --- linux-2.6.9-rc1-mm4
Total 0:35.79 System 33.89 User 1.88
Total 0:35.44 System 33.58 User 1.85
Total 0:35.75 System 33.81 User 1.91
Total 0:35.89 System 34.03 User 1.82
Total 0:35.93 System 34.03 User 1.84

No-bitmap without this micro-optimization patch
Total 0:37.58 System 35.69 User 1.89
Total 0:37.52 System 35.66 User 1.86
Total 0:37.56 System 35.68 User 1.88
Total 0:37.64 System 35.76 User 1.88
Total 0:37.72 System 35.89 User 1.82

No-bitmap with this micro-optimization patch.
Total 0:35.28 System 33.45 User 1.81
Total 0:35.38 System 33.62 User 1.75
Total 0:35.44 System 33.58 User 1.84
Total 0:35.52 System 33.58 User 1.90
Total 0:35.79 System 33.92 User 1.81

Single-user-mode.

reference-kernel  linux-2.6.9-rc1-mm4:
Total 0:35.20 System 33.32 User 1.88
Total 0:35.23 System 33.37 User 1.85
Total 0:35.58 System 33.77 User 1.81
Total 0:35.49 System 33.60 User 1.90
Total 0:35.79 System 33.80 User 1.99

No-bitmap without this micro-optimization patch
Total 0:36.83 System 35.16 User 1.67
Total 0:36.45 System 34.66 User 1.79
Total 0:36.81 System 35.10 User 1.70
Total 0:36.89 System 35.24 User 1.65
Total 0:36.82 System 35.14 User 1.68

No-bitmap with this micor-optimization patch:
Total 0:34.97 System 33.07 User 1.89
Total 0:34.94 System 32.98 User 1.95
Total 0:34.99 System 33.11 User 1.87
Total 0:34.90 System 33.14 User 1.76
Total 0:34.92 System 33.02 User 1.90


Results with this patch is better than ones without this by 2 seconds.
2/1000 = 2ms per 1 iteration (for 16 Megabytes alloc/free).

Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

---

  test-kernel-kamezawa/include/linux/page-flags.h |    2 ++
  test-kernel-kamezawa/mm/page_alloc.c            |    8 ++++----
  2 files changed, 6 insertions(+), 4 deletions(-)

diff -puN include/linux/page-flags.h~eliminate-bitmap-opt include/linux/page-flags.h
--- test-kernel/include/linux/page-flags.h~eliminate-bitmap-opt	2004-09-08 18:48:43.115922392 +0900
+++ test-kernel-kamezawa/include/linux/page-flags.h	2004-09-08 18:48:43.120921632 +0900
@@ -239,6 +239,8 @@ extern unsigned long __read_page_state(u
  #define SetPagePrivate(page)	set_bit(PG_private, &(page)->flags)
  #define ClearPagePrivate(page)	clear_bit(PG_private, &(page)->flags)
  #define PagePrivate(page)	test_bit(PG_private, &(page)->flags)
+#define __SetPagePrivate(page)  __set_bit(PG_private, &(page)->flags)
+#define __ClearPagePrivate(page) __clear_bit(PG_private, &(page)->flags)

  #define PageWriteback(page)	test_bit(PG_writeback, &(page)->flags)
  #define SetPageWriteback(page)						\
diff -puN mm/page_alloc.c~eliminate-bitmap-opt mm/page_alloc.c
--- test-kernel/mm/page_alloc.c~eliminate-bitmap-opt	2004-09-08 18:48:43.118921936 +0900
+++ test-kernel-kamezawa/mm/page_alloc.c	2004-09-08 18:48:43.123921176 +0900
@@ -242,11 +242,11 @@ static inline void __free_pages_bulk (st
  		page_idx &= buddy_idx;
  		list_del(&buddy->lru);
  		/* for propriety of PG_private bit, we clear it */
-		ClearPagePrivate(buddy);
+		__ClearPagePrivate(buddy);
  	}
  	/* record the final order of the page */
  	coalesced_page = base + page_idx;
-	SetPagePrivate(coalesced_page);
+	__SetPagePrivate(coalesced_page);
  	set_page_order(coalesced_page,order);
  	list_add(&coalesced_page->lru, &zone->free_area[order].free_list);
  }
@@ -347,7 +347,7 @@ expand(struct zone *zone, struct page *p
  		list_add(&page[size].lru, &area->free_list);
  		/* Note: already have lock, we don't need to use atomic ops */
  		set_page_order(&page[size], high);
-		SetPagePrivate(&page[size]);
+		__SetPagePrivate(&page[size]);
  	}
  	return page;
  }
@@ -410,7 +410,7 @@ static struct page *__rmqueue(struct zon
  		page = list_entry(area->free_list.next, struct page, lru);
  		list_del(&page->lru);
  		/* Note: already have lock, we don't need to use atomic ops */
-		ClearPagePrivate(page);
+		__ClearPagePrivate(page);
  		zone->free_pages -= 1UL << order;
  		return expand(zone, page, order, current_order, area);
  	}

_

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

             reply	other threads:[~2004-09-08 12:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-08 12:08 Hiroyuki KAMEZAWA [this message]
2004-09-08 12:08 ` [RFC][PATCH] no bitmap buddy allocator : removing atomic ops (4/4) Hiroyuki KAMEZAWA
2004-09-09  6:00 ` Hiroyuki KAMEZAWA
2004-09-09  6:00   ` Hiroyuki KAMEZAWA

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=413EF64B.2060407@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=akpm@osdl.org \
    --cc=haveblue@us.ibm.com \
    --cc=lhms-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=taka@valinux.co.jp \
    --cc=wli@holomorphy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.