linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Sheng Yang <sheng@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, linux-mm <linux-mm@kvack.org>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] x86: Extend test_and_set_bit() test_and_clean_bit() to 64 bits in X86_64
Date: Wed, 13 May 2009 09:18:34 -0700	[thread overview]
Message-ID: <4A0AF2DA.2020404@zytor.com> (raw)
In-Reply-To: <1242202647-32446-1-git-send-email-sheng@linux.intel.com>

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

Sheng Yang wrote:
> This fix 44/45 bit width memory can't boot up issue. The reason is
> free_bootmem_node()->mark_bootmem_node()->__free() use test_and_clean_bit() to
> clean node_bootmem_map, but for 44bits width address, the idx set bit 31 (43 -
> 12), which consider as a nagetive value for bts.
> 
> This patch applied to tip/mm.

Hi Sheng,

Could you try the attached patch instead?

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 3886 bytes --]

diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index e020366..ccc1bd4 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -50,6 +50,11 @@ Protocol 2.08:	(Kernel 2.6.26) Added crc32 checksum and ELF format
 Protocol 2.09:	(Kernel 2.6.26) Added a field of 64-bit physical
 		pointer to single linked list of struct	setup_data.
 
+Protocol 2.10:	(Kernel 2.6.31?) A protocol for relaxed alignment
+	 	beyond the kernel_alignment added, new init_size and
+	 	pref_address fields.
+	 	
+
 **** MEMORY LAYOUT
 
 The traditional memory map for the kernel loader, used for Image or
@@ -173,7 +178,7 @@ Offset	Proto	Name		Meaning
 022C/4	2.03+	ramdisk_max	Highest legal initrd address
 0230/4	2.05+	kernel_alignment Physical addr alignment required for kernel
 0234/1	2.05+	relocatable_kernel Whether kernel is relocatable or not
-0235/1	N/A	pad2		Unused
+0235/1	2.10+	min_alignment	Minimum alignment, as a power of 2
 0236/2	N/A	pad3		Unused
 0238/4	2.06+	cmdline_size	Maximum size of the kernel command line
 023C/4	2.07+	hardware_subarch Hardware subarchitecture
@@ -182,6 +187,8 @@ Offset	Proto	Name		Meaning
 024C/4	2.08+	payload_length	Length of kernel payload
 0250/8	2.09+	setup_data	64-bit physical pointer to linked list
 				of struct setup_data
+0258/8	2.10+	pref_address	Preferred loading address
+0260/4	2.10+	init_size	Linear memory required during initialization
 
 (1) For backwards compatibility, if the setup_sects field contains 0, the
     real value is 4.
@@ -482,11 +489,15 @@ Protocol:	2.03+
   0x37FFFFFF, you can start your ramdisk at 0x37FE0000.)
 
 Field name:	kernel_alignment
-Type:		read (reloc)
+Type:		read/modify (reloc)
 Offset/size:	0x230/4
-Protocol:	2.05+
+Protocol:	2.05+ (read), 2.10+ (modify)
 
-  Alignment unit required by the kernel (if relocatable_kernel is true.)
+  Alignment unit required by the kernel (if relocatable_kernel is
+  true.)  Starting with protocol version 2.10, this reflects the
+  kernel alignment preferred for optimal performance and can be
+  modified by the loader; see the min_alignment and pref_address field
+  below.
 
 Field name:	relocatable_kernel
 Type:		read (reloc)
@@ -498,6 +509,22 @@ Protocol:	2.05+
   After loading, the boot loader must set the code32_start field to
   point to the loaded code, or to a boot loader hook.
 
+Field name:	min_alignment
+Type:		read (reloc)
+Offset/size:	0x235/1
+Protocol:	2.10+
+
+  This field, if nonzero, indicates as a power of 2 the minimum
+  alignment required, as opposed to preferred, by the kernel to boot.
+  If a boot loader makes use of this field, it should update the
+  kernel_alignment field with the alignment unit desired; typically:
+
+	kernel_alignment = 1 << min_alignment
+
+  There may be a considerable performance cost with an excessively
+  misaligned kernel.  Therefore, a loader should typically try each
+  power-of-two alignment from kernel_alignment down to this alignment.
+
 Field name:	cmdline_size
 Type:		read
 Offset/size:	0x238/4
@@ -582,6 +609,27 @@ Protocol:	2.09+
   sure to consider the case where the linked list already contains
   entries.
 
+Field name:	pref_address
+Type:		read (reloc)
+Offset/size:	0x258/8
+Protocol:	2.10+
+
+  This field, if nonzero, represents a preferred load address for the
+  kernel.  A relocating bootloader should attempt to load at this
+  address if possible.
+
+
+Field name:	init_size
+Type:		read
+Offset/size:	0x25c/4
+
+  This field indicates the amount of linear contiguous memory starting
+  at the kernel load address (rounded up to kernel_alignment) that the
+  kernel needs before it is capable of examining its memory map.  This
+  is not the same thing as the total amount of memory the kernel needs
+  to boot, but it can be used by a relocating boot loader to help
+  select a safe load address for the kernel.
+
 
 **** THE IMAGE CHECKSUM
 

  parent reply	other threads:[~2009-05-13 16:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-13  8:17 [PATCH] x86: Extend test_and_set_bit() test_and_clean_bit() to 64 bits in X86_64 Sheng Yang
2009-05-13  8:38 ` Andi Kleen
2009-05-14  3:45   ` Sheng Yang
2009-05-14  8:32     ` Andi Kleen
2009-05-14 14:09       ` H. Peter Anvin
2009-05-14 14:16         ` Andi Kleen
2009-05-14 14:16           ` H. Peter Anvin
2009-05-14 14:27             ` Andi Kleen
2009-05-14 14:25               ` H. Peter Anvin
2009-05-14 14:33                 ` Andi Kleen
2009-05-14 14:36                   ` H. Peter Anvin
2009-05-13 16:18 ` H. Peter Anvin [this message]
2009-05-13 16:55   ` H. Peter Anvin
2009-05-13 17:29     ` H. Peter Anvin
2009-05-14  3:52       ` Sheng Yang
2009-05-14 14:09         ` H. Peter Anvin
2009-05-14 13:57 ` Christoph Hellwig
2009-05-14 14:29   ` H. Peter Anvin

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=4A0AF2DA.2020404@zytor.com \
    --to=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=sheng@linux.intel.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;
as well as URLs for NNTP newsgroup(s).