[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BF17A50.1050905@oracle.com>
Date: Mon, 17 May 2010 10:18:08 -0700
From: Yinghai <yinghai.lu@...cle.com>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
CC: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
David Miller <davem@...emloft.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 15/35] x86, lmb: Add lmb_reserve_area_overlap_ok()
On 05/17/2010 12:24 AM, Benjamin Herrenschmidt wrote:
> On Sun, 2010-05-16 at 23:11 -0700, Yinghai wrote:
>> so looks like your change will hit 2.6.35, and my x86 changes will hit
>> 2.6.36?
>>
>> that is too long.
>
> No. Both will hit 2.6.36. It's way too late to queue up such changes for
> the 2.6.35 merge window which has already opened.
i have feeling that your new LMB code will hit 2.6.36. and
x86 patches that is using to lmb will hit 2.6.37.
otherwise it will make more merge conflicts between tip and lmb.
unless put your lmb change to tip?
>
> Why would it be "too long" ? I keep asking what the heck is going on
> with having a time bomb on those patches and yet have to get a
> satisfactory answer.
why are you thinking that there is time bomb in the patches?
I even provide the option to use x86 own low to high allocation.
really don't know where is the time bomb.
my -v14 patches only touch several lines your core lmb code, and have near 0 affect
to original lmb users.
YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists