All of lore.kernel.org
 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: 34+ 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:17 ` Sheng Yang
2009-05-13  8:38 ` Andi Kleen
2009-05-13  8:38   ` Andi Kleen
2009-05-14  3:45   ` Sheng Yang
2009-05-14  3:45     ` Sheng Yang
2009-05-14  8:32     ` Andi Kleen
2009-05-14  8:32       ` Andi Kleen
2009-05-14 14:09       ` H. Peter Anvin
2009-05-14 14:09         ` H. Peter Anvin
2009-05-14 14:16         ` Andi Kleen
2009-05-14 14:16           ` Andi Kleen
2009-05-14 14:16           ` H. Peter Anvin
2009-05-14 14:16             ` H. Peter Anvin
2009-05-14 14:27             ` Andi Kleen
2009-05-14 14:27               ` Andi Kleen
2009-05-14 14:25               ` H. Peter Anvin
2009-05-14 14:25                 ` H. Peter Anvin
2009-05-14 14:33                 ` Andi Kleen
2009-05-14 14:33                   ` Andi Kleen
2009-05-14 14:36                   ` H. Peter Anvin
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 16:55     ` H. Peter Anvin
2009-05-13 17:29     ` H. Peter Anvin
2009-05-14  3:52       ` Sheng Yang
2009-05-14  3:52         ` Sheng Yang
2009-05-14 14:09         ` H. Peter Anvin
2009-05-14 14:09           ` H. Peter Anvin
2009-05-14 13:57 ` Christoph Hellwig
2009-05-14 13:57   ` Christoph Hellwig
2009-05-14 14:29   ` H. Peter Anvin
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 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.