linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
To: linux-mm <linux-mm@kvack.org>, LHMS <lhms-devel@lists.sourceforge.net>
Cc: William Lee Irwin III <wli@holomorphy.com>,
	Dave Hansen <haveblue@us.ibm.com>,
	Hirokazu Takahashi <taka@valinux.co.jp>,
	ncunningham@linuxmail.org
Subject: [RFC/PATCH] free_area[] bitmap elimination[0/3]
Date: Tue, 24 Aug 2004 21:21:37 +0900	[thread overview]
Message-ID: <412B32D1.10005@jp.fujitsu.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]

Thanks for many comments on previous RFC.

This is an updated version of free_area[] bitmap elimination patch.
Many advices are reflected.
I tested this on Xeon x 2 server and Itanium2 x 2 server.

This removes bitmaps from the buddy allocator.
Instead of using bitmap, this patch records a free page's order to
page struct itself.

Most important point I changed in this version is that tricky usage of
page->private is removed.Instead of doing so,I use PG_private bit now.

If a page is page_count(page)== 0 && PagePrivate(page), it is a head of
contiguous free page on the buddy allocator and its order is page->private.

Propriety of using PG_private is guaranteed by these facts:
(1) Before calling free_pages(), PG_private must be cleared.(see free_pages_check())
(2) Swap calls, which directly call put_page_testzero(), does not uses PG_private bit.
    Because they calls free_hot_cold_page() directly, PG_private bit is not set when
    page_count(page) becomes zero.
(3) All operation of set and clear PG_private bit of a free page for buddy allocator
    is done only while zone->lock() is acquired.

I added zone->aligned_order member in zone struct for avoiding range check to some extent.
This member guarantees a page has a buddy in an order <= zone->aligned_order and
we can skip some checks.

In this version, a problem of pfn_valid() for ia64 is not fixed.
I think I'll need some different kind of patch to fix this.

I added detailed description but complexity is unchaned.

How to patch :
1) patch -p1 < eliminate-bitmap-includes.patch
2) patch -p1 < eliminate-bitmap-init.patch
3) patch -p1 < eliminate-bitmap-alloc.patch
4) patch -p1 < eliminate-bitmap-free.patch


Thanks
--Kame

-- 
--the clue is these footmarks leading to the door.--
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>



[-- Attachment #2: eliminate-bitmap-includes.patch --]
[-- Type: text/x-patch, Size: 4195 bytes --]


This patch removes bitmap from buddy allocator, 
removes free_area_t's bitmap in include/linux/mmzone.h
and adds some definition in include/linux/mm.h

Currently,Linux's page allocator uses buddy algorithm and codes for buddy 
allocator uses bitmap. For what is bitmap is used ?

(*) for recording "a page is free" and its order.

If a page is free and is a head of contiguous free pages of order 'X',
we can record it by
set_bit(free_area[X]->bitmap, index_of_page)

For coalescing, when there is a chunk of free pages of order 'X', 
we can test whether we can coalesce or not by, 
test_bit(free_aera[X]->bitmap,index_of_buddy) 
index_of_buddy can be calculated by (index_of_page ^ (1 << order))

This patch removes bitmap and recording a free page's order 
in its page->private field. If a page is free and it is a head of a free
memory chunk, page->private indicates the order of the page.
and PG_private bit is used to show propriety of information.

For coalescing, when there is a page which is a chunk of free pages of order 'X',
we can test whether we can coalesce or not by
(page_is_free(buddy) && PagePrivate(buddy) && page_order(buddy) == 'X')
address of buddy can be calculated by the same way in bitmap case.

If page is free and on the buddy system, PG_private bit is set and has its order 
in page->private. This scheme is safe because...
(a) when page is being freed, PG_private is not set. (see free_pages_check())
(b) when page is free and on the buddy system, PG_private is set.
These facts are guaranteed by zone->lock.
Only one thread can change a free page's PG_private bit and private field 
at anytime.

in mmzone.h, zone->aligned_order is added. this is explained in next patch.

-- Kame


---

 linux-2.6.8.1-mm4-kame-kamezawa/include/linux/mm.h     |   20 +++++++++++++++++
 linux-2.6.8.1-mm4-kame-kamezawa/include/linux/mmzone.h |    4 ++-
 2 files changed, 23 insertions(+), 1 deletion(-)

diff -puN include/linux/mm.h~eliminate-bitmap-includes include/linux/mm.h
--- linux-2.6.8.1-mm4-kame/include/linux/mm.h~eliminate-bitmap-includes	2004-08-23 11:06:43.000000000 +0900
+++ linux-2.6.8.1-mm4-kame-kamezawa/include/linux/mm.h	2004-08-24 18:25:03.351544872 +0900
@@ -209,6 +209,9 @@ struct page {
 					 * usually used for buffer_heads
 					 * if PagePrivate set; used for
 					 * swp_entry_t if PageSwapCache
+					 * When page is free:  
+					 * this indicates order of page
+					 * in buddy allocator.
 					 */
 	struct address_space *mapping;	/* If low bit clear, points to
 					 * inode address_space, or NULL.
@@ -322,6 +325,23 @@ static inline void put_page(struct page 
 #endif		/* CONFIG_HUGETLB_PAGE */
 
 /*
+ * These macros are used in alloc_pages()/free_pages(), buddy allocator.
+ * page_order(page) returns an order of a free page in buddy allocator.
+ * set_page_order(page, order) sets an order of a free page in buddy allocator.
+ * Invalidate_page_order() invalidates order information for avoiding
+ * conflicts of pages in transition state.
+ *
+ * this is used with PG_private flag
+ */ 
+#define set_page_order(page,order)\
+        do {\
+            (page)->private = (order);\
+            SetPagePrivate((page));\
+        } while(0)
+#define invalidate_page_order(page) ClearPagePrivate((page))
+#define page_order(page) ((page)->private)
+
+/*
  * Multiple processes may "see" the same page. E.g. for untouched
  * mappings of /dev/null, all processes see the same page full of
  * zeroes, and text pages of executables and shared libraries have
diff -puN include/linux/mmzone.h~eliminate-bitmap-includes include/linux/mmzone.h
--- linux-2.6.8.1-mm4-kame/include/linux/mmzone.h~eliminate-bitmap-includes	2004-08-23 11:47:01.000000000 +0900
+++ linux-2.6.8.1-mm4-kame-kamezawa/include/linux/mmzone.h	2004-08-24 13:07:28.000000000 +0900
@@ -22,7 +22,6 @@
 
 struct free_area {
 	struct list_head	free_list;
-	unsigned long		*map;
 };
 
 struct pglist_data;
@@ -163,7 +162,10 @@ struct zone {
 
 	/*
 	 * free areas of different sizes
+	 * aligned_order shows the upper bound of aligned order,
+	 * aligned_order means every page below it has a buddy.
 	 */
+	int			aligned_order; 
 	struct free_area	free_area[MAX_ORDER];
 
 	/*

_

             reply	other threads:[~2004-08-24 12:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-24 12:21 Hiroyuki KAMEZAWA [this message]
2004-08-24 16:53 ` Dave Hansen
2004-08-24 23:43   ` [Lhms-devel] " 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=412B32D1.10005@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=haveblue@us.ibm.com \
    --cc=lhms-devel@lists.sourceforge.net \
    --cc=linux-mm@kvack.org \
    --cc=ncunningham@linuxmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox