All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Linux Kernel ML <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	lhms <lhms-devel@lists.sourceforge.net>,
	William Lee Irwin III <wli@holomorphy.com>
Subject: Re: [Lhms-devel] Re: [RFC] buddy allocator without bitmap [3/4]
Date: Thu, 26 Aug 2004 17:15:08 -0700	[thread overview]
Message-ID: <1093565707.2984.394.camel@nighthawk> (raw)
In-Reply-To: <412E7AB6.8020707@jp.fujitsu.com>

On Thu, 2004-08-26 at 17:05, Hiroyuki KAMEZAWA wrote:
> Currently, I think zone->nr_mem_map itself is very vague.
> I'm now looking for another way to remove this part entirely.
> 
> I think mem_section approarch may be helpful to remove this part,
> but to implement full feature of CONFIG_NONLINEAR,
> I'll need lots of different kind of patches.
> (If mem_map is guaranteed to be contiguous in one mem_section)

This is definitely a true assumption right now.  

> 1. Now, I think some small parts, some essence of mem_section which
>    makes pfn_valid() faster may be good.

The only question is what it will take when there's a partially populate
mem_section.  We'll almost certainly have to allow it, but the real
question is whether or not we will ever have a partially populated one
that's not at the end of memory.  

> And another way,
> 
> 2. A method which enables page -> page's max_order calculation
>    may be good and consistent way in this no-bitmap approach.
> 
> But this problem would be my week-end homework :).

Instead of adding more stuff to the mem_section, we might be able to
(ab)use more stuff in the mem_map's mem_map, like I am with
page->section right now.  

-- Dave


WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <haveblue@us.ibm.com>
To: Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Linux Kernel ML <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	lhms <lhms-devel@lists.sourceforge.net>,
	William Lee Irwin III <wli@holomorphy.com>
Subject: Re: [Lhms-devel] Re: [RFC] buddy allocator without bitmap [3/4]
Date: Thu, 26 Aug 2004 17:15:08 -0700	[thread overview]
Message-ID: <1093565707.2984.394.camel@nighthawk> (raw)
In-Reply-To: <412E7AB6.8020707@jp.fujitsu.com>

On Thu, 2004-08-26 at 17:05, Hiroyuki KAMEZAWA wrote:
> Currently, I think zone->nr_mem_map itself is very vague.
> I'm now looking for another way to remove this part entirely.
> 
> I think mem_section approarch may be helpful to remove this part,
> but to implement full feature of CONFIG_NONLINEAR,
> I'll need lots of different kind of patches.
> (If mem_map is guaranteed to be contiguous in one mem_section)

This is definitely a true assumption right now.  

> 1. Now, I think some small parts, some essence of mem_section which
>    makes pfn_valid() faster may be good.

The only question is what it will take when there's a partially populate
mem_section.  We'll almost certainly have to allow it, but the real
question is whether or not we will ever have a partially populated one
that's not at the end of memory.  

> And another way,
> 
> 2. A method which enables page -> page's max_order calculation
>    may be good and consistent way in this no-bitmap approach.
> 
> But this problem would be my week-end homework :).

Instead of adding more stuff to the mem_section, we might be able to
(ab)use more stuff in the mem_map's mem_map, like I am with
page->section right now.  

-- Dave

--
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-08-27  0:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-26 12:10 [RFC] buddy allocator without bitmap [3/4] Hiroyuki KAMEZAWA
2004-08-26 12:10 ` Hiroyuki KAMEZAWA
2004-08-26 15:55 ` Dave Hansen
2004-08-26 15:55   ` Dave Hansen
2004-08-27  0:05   ` [Lhms-devel] " Hiroyuki KAMEZAWA
2004-08-27  0:05     ` Hiroyuki KAMEZAWA
2004-08-27  0:15     ` Dave Hansen [this message]
2004-08-27  0:15       ` Dave Hansen
2004-08-27  0:42       ` Hiroyuki KAMEZAWA
2004-08-27  0:42         ` 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=1093565707.2984.394.camel@nighthawk \
    --to=haveblue@us.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=lhms-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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.