On Fri, Aug 23, 2013 at 01:08:56PM -0700, Yinghai Lu wrote:
> On Fri, Aug 23, 2013 at 11:25 AM, H. Peter Anvin wrote:
> >
> > BRK makes sense as long as you can set a sane O(1) size limit.
> >
> >>
> >>put the acpi override table in BRK, we still need ok from HPA.
> >>I have impression that he did
> So we need to allocate memory. That is why you suggested to use BRK, right ?
> And the size seems to be a problem.
>
> So I suggest to use early_ioremap().
>
> 1. After paging is enabled, before direct mapping page tables are
> setup, we map the
> initrd with early_ioremap(). And we are able
Hi Yinghai,
2013/8/24 Yinghai Lu :
> On Fri, Aug 23, 2013 at 2:50 PM, chen tang wrote:
>>>
>>> so the DSDT is 7F493E, and total is more than 8M.
>>>
>>> that will need BRK to be extended 16M?
>>>
>>
>> Then how about use early_ioremap(), and don't do it that early in
>> head_32 and head64 ?
>
> w
On Fri, Aug 23, 2013 at 2:50 PM, chen tang wrote:
>>
>> so the DSDT is 7F493E, and total is more than 8M.
>>
>> that will need BRK to be extended 16M?
>>
>
> Then how about use early_ioremap(), and don't do it that early in
> head_32 and head64 ?
why could early_ioremap() help?
when to use early
On Fri, Aug 23, 2013 at 2:52 PM, Moore, Robert wrote:
> While we're at it:
>
> Can someone send me the acpidump for this machine? We very much would like to
> test all of ACPICA with such a large DSDT.
That is Russ.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
: Yinghai Lu
> Cc: Russ Anderson; H. Peter Anvin; Zhang Yanfei; Toshi Kani; Tejun Heo;
> Tang Chen; Konrad Rzeszutek Wilk; Moore, Robert; Zheng, Lv; Rafael J.
> Wysocki; Ingo Molnar; Andrew Morton; Thomas Renninger; Yasuaki Ishimatsu;
> Mel Gorman; Linux Kernel Mailing List
> Subject:
Hi Yinghai,
2013/8/24 Yinghai Lu :
> On Fri, Aug 23, 2013 at 1:30 PM, Russ Anderson wrote:
>> On Fri, Aug 23, 2013 at 01:08:56PM -0700, Yinghai Lu wrote:
>>> On Fri, Aug 23, 2013 at 11:25 AM, H. Peter Anvin wrote:
>
>>> Russ, What is ACPI table size on your big machine?
>>
>> This is from a 256
On Fri, Aug 23, 2013 at 1:30 PM, Russ Anderson wrote:
> On Fri, Aug 23, 2013 at 01:08:56PM -0700, Yinghai Lu wrote:
>> On Fri, Aug 23, 2013 at 11:25 AM, H. Peter Anvin wrote:
>> Russ, What is ACPI table size on your big machine?
>
> This is from a 256 socket 32TB system.
>
> Reserving 256MB of
On Fri, Aug 23, 2013 at 01:08:56PM -0700, Yinghai Lu wrote:
> On Fri, Aug 23, 2013 at 11:25 AM, H. Peter Anvin wrote:
> >
> > BRK makes sense as long as you can set a sane O(1) size limit.
> >
> >>
> >>put the acpi override table in BRK, we still need ok from HPA.
> >>I have impression that he did
On Fri, Aug 23, 2013 at 11:25 AM, H. Peter Anvin wrote:
>
> BRK makes sense as long as you can set a sane O(1) size limit.
>
>>
>>put the acpi override table in BRK, we still need ok from HPA.
>>I have impression that he did not like it, so want to confirm from him.
on 8 sockets system:
-rw-r--r-
Hello Zhang,
On Sat, 2013-08-24 at 00:54 +0800, Zhang Yanfei wrote:
> > Tang, what do you think? Are you OK to try Tejun's suggestion as well?
> >
>
> By saying TJ's suggestion, you mean, we will let memblock to control the
> behaviour, that said, we will do early allocations near the kernel i
Hi Toshi,
On 08/24/2013 01:13 AM, Toshi Kani wrote:
> Hello,
>
> On Fri, 2013-08-23 at 12:24 -0400, Tejun Heo wrote:
>> On Fri, Aug 23, 2013 at 10:14:08AM -0600, Toshi Kani wrote:
>>> I still think acpi table info should be available earlier, but I do not
>>> think I can convince you on this. Th
Hello,
On Fri, 2013-08-23 at 12:24 -0400, Tejun Heo wrote:
> On Fri, Aug 23, 2013 at 10:14:08AM -0600, Toshi Kani wrote:
> > I still think acpi table info should be available earlier, but I do not
> > think I can convince you on this. This can be religious debate.
>
> I'm curious. If there aren
Hello
On 08/24/2013 12:14 AM, Toshi Kani wrote:
> Hello,
>
> On Fri, 2013-08-23 at 09:04 -0400, Tejun Heo wrote:
>> On Thu, Aug 22, 2013 at 04:17:41PM -0600, Toshi Kani wrote:
>>> I am relatively new to Linux, so I am not a good person to elaborate
>>> this. From my experience on other OS, huge
Hello,
On Fri, Aug 23, 2013 at 10:14:08AM -0600, Toshi Kani wrote:
> I still think acpi table info should be available earlier, but I do not
> think I can convince you on this. This can be religious debate.
I'm curious. If there aren't substantial enough benefits, why would
you still want to pu
Hello,
On Fri, 2013-08-23 at 09:04 -0400, Tejun Heo wrote:
> On Thu, Aug 22, 2013 at 04:17:41PM -0600, Toshi Kani wrote:
> > I am relatively new to Linux, so I am not a good person to elaborate
> > this. From my experience on other OS, huge pages helped for the kernel,
> > but did not necessarily
On Fri, Aug 23, 2013 at 10:35:07AM -0400, Tejun Heo wrote:
> Yeah, it's true that MTRRs are nasty. On the other hand, we've been
> doing that for over a decade and are still doing it anyway if I'm not
> mistaken. It probably isn't a big difference but it's still a bit sad
> that this is likely ca
Hello,
On Fri, Aug 23, 2013 at 04:24:06PM +0200, H. Peter Anvin wrote:
> Well... relying on MTRRs is a big cost in complexity and failure modes.
Yeah, it's true that MTRRs are nasty. On the other hand, we've been
doing that for over a decade and are still doing it anyway if I'm not
mistaken. It
Well... relying on MTRRs is a big cost in complexity and failure modes.
Tejun Heo wrote:
>Hello,
>
>On Fri, Aug 23, 2013 at 03:08:55PM +0200, H. Peter Anvin wrote:
>> What is the point of 1G+MTRR? If there are caching differences the
>> TLB will fracture the pages anyway.
>
>Ah, right. Consumin
Hello,
On Fri, Aug 23, 2013 at 03:08:55PM +0200, H. Peter Anvin wrote:
> What is the point of 1G+MTRR? If there are caching differences the
> TLB will fracture the pages anyway.
Ah, right. Consuming less memory / cachelines would still be a small
advantage tho unless creating split TLB from lar
What is the point of 1G+MTRR? If there are caching differences the TLB will
fracture the pages anyway.
Tejun Heo wrote:
>Hello, Toshi.
>
>On Thu, Aug 22, 2013 at 04:17:41PM -0600, Toshi Kani wrote:
>> I am relatively new to Linux, so I am not a good person to elaborate
>> this. From my experie
Hello, Toshi.
On Thu, Aug 22, 2013 at 04:17:41PM -0600, Toshi Kani wrote:
> I am relatively new to Linux, so I am not a good person to elaborate
> this. From my experience on other OS, huge pages helped for the kernel,
> but did not necessarily help user applications. It depended on
> applicatio
Hello Tejun,
On Thu, 2013-08-22 at 17:21 -0400, Tejun Heo wrote:
:
> > Local page table and memory hotplug are two separate things. That is,
> > local page tables can be supported on all NUMA platforms without hotplug
> > support. Are you sure huge mapping will solve everything for all types
>
Hello, Toshi.
On Thu, Aug 22, 2013 at 03:06:38PM -0600, Toshi Kani wrote:
> Since some node(s) won't be ejectable, this solution is reasonable as
> the first step. I do not think it is a distraction. I view your
But does this contribute to reaching the next step? If so, how?
I can't see how an
On Thu, 2013-08-22 at 16:21 -0400, Tejun Heo wrote:
> On Thu, Aug 22, 2013 at 02:11:32PM -0600, Toshi Kani wrote:
> > It's too late for the kernel image itself, but it prevents allocating
> > kernel memory from movable ranges after that. I'd say it solves a half
> > of the issue this time.
>
> Th
A bit of addition.
On Thu, Aug 22, 2013 at 04:21:58PM -0400, Tejun Heo wrote:
> That works if such half solution eventually leads to the full
> solution. This is just a distraction. You are already too late in
> the boot sequence. It doesn't even qualify as a half solution. It's
> like obsessi
Hello,
On Thu, Aug 22, 2013 at 02:11:32PM -0600, Toshi Kani wrote:
> It's too late for the kernel image itself, but it prevents allocating
> kernel memory from movable ranges after that. I'd say it solves a half
> of the issue this time.
That works if such half solution eventually leads to the f
Hello Tejun,
On Thu, 2013-08-22 at 14:31 -0400, Tejun Heo wrote:
> On Thu, Aug 22, 2013 at 09:52:09AM -0600, Toshi Kani wrote:
> > I understand that you are concerned about stability of the ACPI stuff,
> > which I think is a valid point, but most of (if not all) of the
> > ACPI-related issues come
Hello,
On Fri, Aug 23, 2013 at 03:39:53AM +0800, Zhang Yanfei wrote:
> What do you mean by "earlyboot"? And also in your previous mail, I am also
> a little confused by what you said "the very first stage of boot". Does
> this mean the stage we are in head_32 or head64.c?
Mostly referring to the
Hello tejun,
On 08/23/2013 02:31 AM, Tejun Heo wrote:
> Hello,
>
> On Thu, Aug 22, 2013 at 09:52:09AM -0600, Toshi Kani wrote:
>> I understand that you are concerned about stability of the ACPI stuff,
>> which I think is a valid point, but most of (if not all) of the
>> ACPI-related issues come f
Hello,
On Thu, Aug 22, 2013 at 09:52:09AM -0600, Toshi Kani wrote:
> I understand that you are concerned about stability of the ACPI stuff,
> which I think is a valid point, but most of (if not all) of the
> ACPI-related issues come from ACPI namespace/methods, which is a very
> different thing.
Hello Tejun,
On Wed, 2013-08-21 at 23:32 -0400, Tejun Heo wrote:
> On Wed, Aug 21, 2013 at 04:36:35PM -0600, Toshi Kani wrote:
> > I agree that ACPI is rather complicated stuff. But in my experience,
> > the majority complication comes from ACPI namespace and methods, not
> > from ACPI tables. D
Hello,
On Wed, Aug 21, 2013 at 04:36:35PM -0600, Toshi Kani wrote:
> I agree that ACPI is rather complicated stuff. But in my experience,
> the majority complication comes from ACPI namespace and methods, not
> from ACPI tables. Do you really think ACPI table init is that risky? I
> consider AC
Hello Tejun,
On Wed, 2013-08-21 at 16:40 -0400, Tejun Heo wrote:
> On Wed, Aug 21, 2013 at 02:29:28PM -0600, Toshi Kani wrote:
> > Platforms vendors (which care Linux) need to support the existing Linux
> > features. This means that they have to implement legacy interfaces on
> > x86 until the ke
Hello, Toshi.
On Wed, Aug 21, 2013 at 02:29:28PM -0600, Toshi Kani wrote:
> Platforms vendors (which care Linux) need to support the existing Linux
> features. This means that they have to implement legacy interfaces on
> x86 until the kernel supports an alternative method. For instance, some
>
Hello Tejun,
On Wed, 2013-08-21 at 15:54 -0400, Tejun Heo wrote:
> On Wed, Aug 21, 2013 at 01:31:43PM -0600, Toshi Kani wrote:
> > Well, there is reason why we have earlyprintk feature today. So, let's
> > not debate on this feature now. There was previous attempt to support
>
> Are you saying
Hello, Toshi.
On Wed, Aug 21, 2013 at 01:31:43PM -0600, Toshi Kani wrote:
> Well, there is reason why we have earlyprintk feature today. So, let's
> not debate on this feature now. There was previous attempt to support
Are you saying the existing earlyprintk automatically justifies
addition of
On Wed, 2013-08-21 at 11:36 -0400, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 21, 2013 at 11:00:26PM +0800, Zhang Yanfei wrote:
> > In current boot order, before we get the SRAT, we have a big consumer of
> > early
> > allocations: we are setting up the page table in top-down (The idea was
> > pr
Hello,
On Wed, Aug 21, 2013 at 11:00:26PM +0800, Zhang Yanfei wrote:
> In current boot order, before we get the SRAT, we have a big consumer of early
> allocations: we are setting up the page table in top-down (The idea was
> proposed by HPA,
> Link: https://lkml.org/lkml/2012/10/4/701). That sai
Hi tejun,
On 08/21/2013 09:06 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 21, 2013 at 06:15:35PM +0800, Tang Chen wrote:
>> [What are we doing]
>>
>> We are trying to initialize acip tables as early as possible. But Linux
>> kernel
>> allows users to override acpi tables by specifying their ow
Hello,
On Wed, Aug 21, 2013 at 06:15:35PM +0800, Tang Chen wrote:
> [What are we doing]
>
> We are trying to initialize acip tables as early as possible. But Linux kernel
> allows users to override acpi tables by specifying their own tables in initrd.
> So we have to do acpi_initrd_override() ear
Hi all,
This patch-set has not been fully tested. I sent them first for you
to review. Please comment if we can agree on this solution.
Thanks.:)
On 08/21/2013 06:15 PM, Tang Chen wrote:
This patch-set aims to move acpi_initrd_override() earlier on x86.
Some of the patches are from Yinghai's p
This patch-set aims to move acpi_initrd_override() earlier on x86.
Some of the patches are from Yinghai's patch-set:
https://lkml.org/lkml/2013/6/14/561
The difference between this patch-set and Yinghai's original patch-set are:
1. This patch-set doesn't split acpi_initrd_override(), but call it a
43 matches
Mail list logo
