linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Sheng Yang <sheng@linux.intel.com>,
	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: Thu, 14 May 2009 07:29:26 -0700	[thread overview]
Message-ID: <4A0C2AC6.3000207@zytor.com> (raw)
In-Reply-To: <20090514135747.GA7926@infradead.org>

Christoph Hellwig wrote:
> On Wed, May 13, 2009 at 04:17:27PM +0800, 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.
> 
> Should we really have different prototypes for these helpers on
> different architectures?
> 

We already do: SPARC and MIPS have unsigned long, and apparently have
been unsigned long for a long time.  Given how the x86 bitops work, they
would have to be signed, which would mean to introduce a third
prototype, which really is the suck, but it's not like it would be the
only oddball.  Either that or we have to redesign the bootmem system for
very large amounts of memory.

	-hpa

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

--
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:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2009-05-14 14:32 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
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 [this message]

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=4A0C2AC6.3000207@zytor.com \
    --to=hpa@zytor.com \
    --cc=hch@infradead.org \
    --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).