All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@saeurebad.de>
To: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>, Yinghai Lu <yhlu.kernel@gmail.com>,
	Andi Kleen <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm 11/14] bootmem: respect goal more likely
Date: Thu, 05 Jun 2008 06:13:47 +0200	[thread overview]
Message-ID: <87abi0semc.fsf@saeurebad.de> (raw)
In-Reply-To: <20080605115235.6453.E1E9C6FF@jp.fujitsu.com> (Yasunori Goto's message of "Thu, 05 Jun 2008 11:58:56 +0900")

Hi,

Yasunori Goto <y-goto@jp.fujitsu.com> writes:

> Hi.
>
>> > I'd like to straggle more, but may be need more time,
>> > because, IA64 doesn't have early_printk, and console is not enable
>> > at here.....
>> 
>> Hm, just to make sure: this is the patch that breaks booting, right?  If
>> you apply all patches in the series before this one, the machine boots
>> fine?
>
> Yes.

Okay.

>> 
>> Could you boot a working image with bootmem_debug in the command line?
>> Perhaps seeing the usual bootmem usage on this box gives a hint what is
>> broken.
>
> Ok. I'll try it.

Thanks!

>> > However, new_start and new_end should be named as new_start_offset and
>> > new_end_offset. They are not index, but offset from start address of
>> > the node.
>> 
>> Yes, that too.  I would also rename last_offset to last_eidx and
>> last_success to last_sidx.  What do you think?
>
> Last_sidx is ok. But, last_offset seems to be used to manage some
> allocated smaller chunks than one page. I'm not sure last_eidx is ok.

Sorry, my fault.

How about last_offset -> last_end_off to reflect that it is the offset
of the last allocations end?

And last_succes -> hint_idx to reflect that it is an index we start
searching from but it is not strict and we fall back if we find nothing
starting from there.  Also free_bootmem* sets it as a hint from where we
could start searching.

I also would set last_success/hint_idx to the _end_ of the successful
allocation (instead of the beginning of it) in alloc_bootmem_core
because we do not want to search for a new free block from the beginning
of the last allocation but rather right after it.

What do you think?

	Hannes

  reply	other threads:[~2008-06-05  4:14 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-03  0:50 [PATCH -mm 00/14] bootmem rewrite v3 Johannes Weiner
2008-06-03  0:50 ` [PATCH -mm 01/14] bootmem: reorder code to match new bootmem structure Johannes Weiner
2008-06-03  0:50 ` [PATCH -mm 02/14] bootmem: clean up bootmem.c file header Johannes Weiner
2008-06-03  0:50 ` [PATCH -mm 03/14] bootmem: add documentation to API functions Johannes Weiner
2008-06-03  0:50 ` [PATCH -mm 04/14] bootmem: add debugging framework Johannes Weiner
2008-06-03  0:50 ` [PATCH -mm 05/14] bootmem: revisit bitmap size calculations Johannes Weiner
2008-06-03  0:50 ` [PATCH -mm 06/14] bootmem: revisit bootmem descriptor list handling Johannes Weiner
2008-06-03  0:50 ` [PATCH -mm 07/14] bootmem: clean up free_all_bootmem_core Johannes Weiner
2008-06-03  0:50 ` [PATCH -mm 08/14] bootmem: clean up alloc_bootmem_core Johannes Weiner
2008-06-03  0:50 ` [PATCH -mm 09/14] bootmem: free/reserve helpers Johannes Weiner
2008-06-03  0:50 ` [PATCH -mm 10/14] bootmem: factor out the marking of a PFN range Johannes Weiner
2008-06-03  0:50 ` [PATCH -mm 11/14] bootmem: respect goal more likely Johannes Weiner
2008-06-03 13:59   ` Yasunori Goto
2008-06-03 16:16     ` Johannes Weiner
2008-06-04 10:55       ` Yasunori Goto
2008-06-04 20:25         ` Johannes Weiner
2008-06-05  2:58           ` Yasunori Goto
2008-06-05  4:13             ` Johannes Weiner [this message]
     [not found]               ` <20080605134455.6457.E1E9C6FF@jp.fujitsu.com>
2008-06-05  8:22                 ` Johannes Weiner
2008-06-05  8:31               ` Yasunori Goto
2008-06-05 16:41                 ` Johannes Weiner
2008-06-06  0:25                   ` Yasunori Goto
2008-06-03  0:50 ` [PATCH -mm 12/14] bootmem: Make __alloc_bootmem_low_node fall back to other nodes Johannes Weiner
2008-06-03  0:50 ` [PATCH -mm 13/14] bootmem: revisit alloc_bootmem_section Johannes Weiner
2008-06-03  0:50 ` [PATCH -mm 14/14] bootmem: replace node_boot_start in struct bootmem_data Johannes Weiner
2008-06-03  0:50   ` Johannes Weiner
  -- strict thread matches above, loose matches on Subject: below --
2008-06-05 22:49 [PATCH -mm 00/14] bootmem rewrite v4 Johannes Weiner
2008-06-05 22:49 ` [PATCH -mm 11/14] bootmem: respect goal more likely Johannes Weiner
2008-05-30 19:42 [PATCH -mm 00/14] bootmem rewrite v2 Johannes Weiner
2008-05-30 19:42 ` [PATCH -mm 11/14] bootmem: respect goal more likely Johannes Weiner
2008-05-30 19:42   ` Johannes Weiner
2008-05-30 20:16   ` Johannes Weiner
2008-05-30 20:16     ` Johannes Weiner

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=87abi0semc.fsf@saeurebad.de \
    --to=hannes@saeurebad.de \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=y-goto@jp.fujitsu.com \
    --cc=yhlu.kernel@gmail.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.