All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
To: Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Linux Kernel ML <linux-kernel@vger.kernel.org>,
	LHMS <lhms-devel@lists.sourceforge.net>,
	linux-mm <linux-mm@kvack.org>, 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: Re: [RFC][PATCH] no bitmap buddy allocator:  remove free_area->map (0/4)
Date: Wed, 08 Sep 2004 21:20:02 +0900	[thread overview]
Message-ID: <413EF8F2.5000904@jp.fujitsu.com> (raw)
In-Reply-To: <413EEFA9.9030007@jp.fujitsu.com>

This is a quick change-log from "previous-version" for comparison.

Big difference from previous one is revival of bad_range() and reduced victim pages.

   -- bad_range() is modified and bad_range_pfn() is added.
   -- bad_range_pfn() uses zone->memmap_start_pfn/memmap_end_pfn instead of using
      zone_start_pfn/spanned_pages. Because IA64's memmap's start is not equal to
      zone->zone_start_pfn.
   -- In most inner loop of __free_pages_bulk(), bad_range_pfn() is used.
   -- this bad_range_pfn() enables me to reduce victim pages.

      In my IA64,
Sep  8 18:59:38 casares kernel: calculate_buddy_range() 36e 129901
Sep  8 18:59:38 casares kernel: victim end page 1feda
Sep  8 18:59:38 casares kernel: calculate_buddy_range() 1fedc 292
Sep  8 18:59:38 casares kernel: victim top page 1fedc
Sep  8 18:59:38 casares kernel: victim top page 1fee0
Sep  8 18:59:38 casares kernel: victim top page 1ff00
Sep  8 18:59:38 casares kernel: victim end page 1ffff
Sep  8 18:59:38 casares kernel: saved end victim page 1ffff
Sep  8 18:59:38 casares kernel: calculate_buddy_range() 40000 262144
Sep  8 18:59:38 casares kernel: calculate_buddy_range() a0000 131072
Sep  8 18:59:38 casares kernel: victim top page a0000
Sep  8 18:59:38 casares kernel: Built 1 zonelists
       # of victim pages is 5. It was 19 in previous version.

   -- ia64's virtual_memmap_init() can call memmap_init() several times for the same
      memory range. It was fixed.

-- Kame


WARNING: multiple messages have this Message-ID (diff)
From: Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
To: Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Linux Kernel ML <linux-kernel@vger.kernel.org>,
	LHMS <lhms-devel@lists.sourceforge.net>,
	linux-mm <linux-mm@kvack.org>, 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: Re: [RFC][PATCH] no bitmap buddy allocator:  remove free_area->map (0/4)
Date: Wed, 08 Sep 2004 21:20:02 +0900	[thread overview]
Message-ID: <413EF8F2.5000904@jp.fujitsu.com> (raw)
In-Reply-To: <413EEFA9.9030007@jp.fujitsu.com>

This is a quick change-log from "previous-version" for comparison.

Big difference from previous one is revival of bad_range() and reduced victim pages.

   -- bad_range() is modified and bad_range_pfn() is added.
   -- bad_range_pfn() uses zone->memmap_start_pfn/memmap_end_pfn instead of using
      zone_start_pfn/spanned_pages. Because IA64's memmap's start is not equal to
      zone->zone_start_pfn.
   -- In most inner loop of __free_pages_bulk(), bad_range_pfn() is used.
   -- this bad_range_pfn() enables me to reduce victim pages.

      In my IA64,
Sep  8 18:59:38 casares kernel: calculate_buddy_range() 36e 129901
Sep  8 18:59:38 casares kernel: victim end page 1feda
Sep  8 18:59:38 casares kernel: calculate_buddy_range() 1fedc 292
Sep  8 18:59:38 casares kernel: victim top page 1fedc
Sep  8 18:59:38 casares kernel: victim top page 1fee0
Sep  8 18:59:38 casares kernel: victim top page 1ff00
Sep  8 18:59:38 casares kernel: victim end page 1ffff
Sep  8 18:59:38 casares kernel: saved end victim page 1ffff
Sep  8 18:59:38 casares kernel: calculate_buddy_range() 40000 262144
Sep  8 18:59:38 casares kernel: calculate_buddy_range() a0000 131072
Sep  8 18:59:38 casares kernel: victim top page a0000
Sep  8 18:59:38 casares kernel: Built 1 zonelists
       # of victim pages is 5. It was 19 in previous version.

   -- ia64's virtual_memmap_init() can call memmap_init() several times for the same
      memory range. It was fixed.

-- Kame

--
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:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-08 11:40 [RFC][PATCH] no bitmap buddy allocator: remove free_area->map (0/4) Hiroyuki KAMEZAWA
2004-09-08 11:40 ` Hiroyuki KAMEZAWA
2004-09-08 12:20 ` Hiroyuki KAMEZAWA [this message]
2004-09-08 12:20   ` 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=413EF8F2.5000904@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.