Freeing ACPI tables after parsing

Freeing ACPI tables after parsing

[Andi Kleen]

[repost, this time with correct cc list]

AFAIK ACPI saves all information found in ACPI tables in memory
somewhere else (please correct me if I'm wrong on that)

I also found this comment in e820.h:

#define E820_ACPI       3 /* usable as RAM once ACPI tables have been read */

Currently I don't see any code that would free the ACPI tables after they
are read. During SLES10 testing we had some problems with the ACPI
tables on some Unisys systems being in a area where the kexec kernel
wanted to be loaded too. Also on other systems the ACPI tables are not
exactly at the end but in the middle of the memory map and for some applications
it might be better to have a lot of physical continuous memory.

So are there any plans to free the BIOS supplied ACPI tables after parsing
or is there some obstacle to that that I'm missing?

Thanks,
-Andi
 

Re: Freeing ACPI tables after parsing

[Alexey Starikovskiy]

Andy,
We are about to release new table code, which will not allocate memory for any tables,
but just map them from their physical location, does it solve the problem you describe?

Regards,
	Alex.

Andi Kleen wrote:
> [repost, this time with correct cc list]
> 
> AFAIK ACPI saves all information found in ACPI tables in memory
> somewhere else (please correct me if I'm wrong on that)
> 
> I also found this comment in e820.h:
> 
> #define E820_ACPI       3 /* usable as RAM once ACPI tables have been read */
> 
> Currently I don't see any code that would free the ACPI tables after they
> are read. During SLES10 testing we had some problems with the ACPI
> tables on some Unisys systems being in a area where the kexec kernel
> wanted to be loaded too. Also on other systems the ACPI tables are not
> exactly at the end but in the middle of the memory map and for some applications
> it might be better to have a lot of physical continuous memory.
> 
> So are there any plans to free the BIOS supplied ACPI tables after parsing
> or is there some obstacle to that that I'm missing?
> 
> Thanks,
> -Andi
>  
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Freeing ACPI tables after parsing

[Andi Kleen]

On Mon, 21 Aug 2006 20:59:57 +0400
Alexey Starikovskiy <alexey_y_starikovskiy@linux.intel.com> wrote:

> Andy,
> We are about to release new table code, which will not allocate memory for any tables,
> but just map them from their physical location, does it solve the problem you describe?

No. In fact it makes it worse. My point was to allocate memory for the tables,
copy them and then free the physical location after it is read.

-Andi

Re: Freeing ACPI tables after parsing

[Len Brown]

On Monday 21 August 2006 05:46, Andi Kleen wrote:
> [repost, this time with correct cc list]
> 
> AFAIK ACPI saves all information found in ACPI tables in memory
> somewhere else (please correct me if I'm wrong on that)
> 
> I also found this comment in e820.h:
> 
> #define E820_ACPI       3 /* usable as RAM once ACPI tables have been read */
> 
> Currently I don't see any code that would free the ACPI tables after they
> are read. 

This is true.

> During SLES10 testing we had some problems with the ACPI 
> tables on some Unisys systems being in a area where the kexec kernel
> wanted to be loaded too. 

Why does the kexec kernel care what physical memory it is loaded into,
and how can it be guaranteed that address is not reserved by the platform firmware?

> Also on other systems the ACPI tables are not 
> exactly at the end but in the middle of the memory map and for some applications
> it might be better to have a lot of physical continuous memory.
> 
> So are there any plans to free the BIOS supplied ACPI tables after parsing
> or is there some obstacle to that that I'm missing?

As Alexey wrote, he and Bob have already deleted the kernel's new copy
of the tables in favor of using them 'in place'.

I guess I'm not clear on the requirement here.
If we were to alter that plan to make a kernel copy -- and release the original BIOS memory --
assuming it is marked such that we can release it -- how do we know that
we are not dropping the new copy someplace that kexec doesn't want it?

-Len

Re: Freeing ACPI tables after parsing

[Andi Kleen]

On Mon, 21 Aug 2006 17:52:16 -0400
Len Brown <len.brown@intel.com> wrote:


> > During SLES10 testing we had some problems with the ACPI 
> > tables on some Unisys systems being in a area where the kexec kernel
> > wanted to be loaded too. 
> 
> Why does the kexec kernel care what physical memory it is loaded into,

At least the one in SLES10 was linked to a fixed address (64MB@64MB)
In the future it will be relocatable, but still there will be defaults
passed in advance.

Unisys ended up fixing it with a new BIOS, but I can well see this
happening again.

> and how can it be guaranteed that address is not reserved by the platform firmware?

I don't think there is a fool proof method right now, just heuristics
However freeing ACPI would avoid some of the potential problems.

> > Also on other systems the ACPI tables are not 
> > exactly at the end but in the middle of the memory map and for some applications
> > it might be better to have a lot of physical continuous memory.
> > 
> > So are there any plans to free the BIOS supplied ACPI tables after parsing
> > or is there some obstacle to that that I'm missing?
> 
> As Alexey wrote, he and Bob have already deleted the kernel's new copy
> of the tables in favor of using them 'in place'.
> 
> I guess I'm not clear on the requirement here.
> If we were to alter that plan to make a kernel copy -- and release the original BIOS memory --
> assuming it is marked such that we can release it -- how do we know that
> we are not dropping the new copy someplace that kexec doesn't want it?

There are other allocations anyways and the allocators tend to cluster, so one would
assume it ends up being ok. If there are conflicts they can be handled in
one single place in Linux. But Linux can't affect the BIOS' choice of table
placement.

Also I suspect the kernel can store it more efficiently in memory. When the tables
are reserved in memory they will be always rounded up/down to page boundaries,
while a kernel allocation can fit it better. At least for some of them (like fadt)
the kernel seems to use globals already too, so the original mapping wouldn't be 
needed.

-Andi
 

Re: Freeing ACPI tables after parsing

[Len Brown]

On Monday 21 August 2006 18:06, Andi Kleen wrote:

> > Why does the kexec kernel care what physical memory it is loaded into,
> 
> At least the one in SLES10 was linked to a fixed address (64MB@64MB)
> In the future it will be relocatable, but still there will be defaults
> passed in advance.
> 
> Unisys ended up fixing it with a new BIOS, but I can well see this
> happening again.

Okay, good to know this is not urgent.  I think we should proceed with our
1-copy-of-the-tables change, and we can independently change it later to
copy them and reclaim the original space if that turns out to work.
 
> > and how can it be guaranteed that address is not reserved by the platform firmware?
> 
> I don't think there is a fool proof method right now, just heuristics
> However freeing ACPI would avoid some of the potential problems.
> 
> > > Also on other systems the ACPI tables are not 
> > > exactly at the end but in the middle of the memory map and for some applications
> > > it might be better to have a lot of physical continuous memory.
> > > 
> > > So are there any plans to free the BIOS supplied ACPI tables after parsing
> > > or is there some obstacle to that that I'm missing?
> > 
> > As Alexey wrote, he and Bob have already deleted the kernel's new copy
> > of the tables in favor of using them 'in place'.
> > 
> > I guess I'm not clear on the requirement here.
> > If we were to alter that plan to make a kernel copy -- and release the original BIOS memory --
> > assuming it is marked such that we can release it -- how do we know that
> > we are not dropping the new copy someplace that kexec doesn't want it?
> 
> There are other allocations anyways and the allocators tend to cluster, so one would
> assume it ends up being ok. If there are conflicts they can be handled in
> one single place in Linux. But Linux can't affect the BIOS' choice of table
> placement.
> 
> Also I suspect the kernel can store it more efficiently in memory. When the tables
> are reserved in memory they will be always rounded up/down to page boundaries,
> while a kernel allocation can fit it better. At least for some of them (like fadt)
> the kernel seems to use globals already too, so the original mapping wouldn't be 
> needed.

This  trade-off may not be risk-free.
I expect that if Windows tests that the BIOS marks the region properly
and frees it, then Linux will be able to also.  Otherwise Linux will fight
a BIOS battle it can't win w/o Windows acting as a BIOS validation test for us.

-Len

Re: Freeing ACPI tables after parsing

[Andi Kleen]

> I expect that if Windows tests that the BIOS marks the region properly
> and frees it, then Linux will be able to also. 

Yes agreed. Before changing it it would be good to find out if Windows
frees it or not. If not there might be BIOS assumptions that they're still 
there.

-Andi

Re: Freeing ACPI tables after parsing

[Alexey Starikovskiy]

Len Brown wrote:
> On Monday 21 August 2006 18:06, Andi Kleen wrote:
> 
>>> Why does the kexec kernel care what physical memory it is loaded into,
>> At least the one in SLES10 was linked to a fixed address (64MB@64MB)
>> In the future it will be relocatable, but still there will be defaults
>> passed in advance.
>>
>> Unisys ended up fixing it with a new BIOS, but I can well see this
>> happening again.
> 
> Okay, good to know this is not urgent.  I think we should proceed with our
> 1-copy-of-the-tables change, and we can independently change it later to
> copy them and reclaim the original space if that turns out to work.
>  
>>> and how can it be guaranteed that address is not reserved by the platform firmware?
>> I don't think there is a fool proof method right now, just heuristics
>> However freeing ACPI would avoid some of the potential problems.
>>
>>>> Also on other systems the ACPI tables are not 
>>>> exactly at the end but in the middle of the memory map and for some applications
>>>> it might be better to have a lot of physical continuous memory.
>>>>
>>>> So are there any plans to free the BIOS supplied ACPI tables after parsing
>>>> or is there some obstacle to that that I'm missing?
>>> As Alexey wrote, he and Bob have already deleted the kernel's new copy
>>> of the tables in favor of using them 'in place'.
>>>
>>> I guess I'm not clear on the requirement here.
>>> If we were to alter that plan to make a kernel copy -- and release the original BIOS memory --
>>> assuming it is marked such that we can release it -- how do we know that
>>> we are not dropping the new copy someplace that kexec doesn't want it?
>> There are other allocations anyways and the allocators tend to cluster, so one would
>> assume it ends up being ok. If there are conflicts they can be handled in
>> one single place in Linux. But Linux can't affect the BIOS' choice of table
>> placement.
>>
>> Also I suspect the kernel can store it more efficiently in memory. When the tables
>> are reserved in memory they will be always rounded up/down to page boundaries,
>> while a kernel allocation can fit it better. At least for some of them (like fadt)
>> the kernel seems to use globals already too, so the original mapping wouldn't be 
>> needed.
> 
> This  trade-off may not be risk-free.
> I expect that if Windows tests that the BIOS marks the region properly
> and frees it, then Linux will be able to also.  Otherwise Linux will fight
> a BIOS battle it can't win w/o Windows acting as a BIOS validation test for us.

Actually FACS table has a global_lock in it (which the BIOS writes too), so it is not movable,
and as all tables are laid contiguously in physical memory, moving some and
leaving FACS is not an option.

Regards,
	Alex.

RE: Freeing ACPI tables after parsing

[Moore, Robert]

> Actually FACS table has a global_lock in it (which the BIOS writes
too),
> so it is not movable,
> and as all tables are laid contiguously in physical memory, moving
some
> and
> leaving FACS is not an option.

This is a very good point. The Global_Lock field of the FACS is not a
pointer to the global lock, it is the actual memory location of the
lock. Therefore, the FACS can only be mapped, it cannot be copied.


> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Alexey Starikovskiy
> Sent: Tuesday, August 22, 2006 3:01 AM
> To: Len Brown
> Cc: Andi Kleen; linux-acpi@vger.kernel.org;
Natalie.Protasevich@unisys.com
> Subject: Re: Freeing ACPI tables after parsing
> 
> Len Brown wrote:
> > On Monday 21 August 2006 18:06, Andi Kleen wrote:
> >
> >>> Why does the kexec kernel care what physical memory it is loaded
into,
> >> At least the one in SLES10 was linked to a fixed address
(64MB@64MB)
> >> In the future it will be relocatable, but still there will be
defaults
> >> passed in advance.
> >>
> >> Unisys ended up fixing it with a new BIOS, but I can well see this
> >> happening again.
> >
> > Okay, good to know this is not urgent.  I think we should proceed
with
> our
> > 1-copy-of-the-tables change, and we can independently change it
later to
> > copy them and reclaim the original space if that turns out to work.
> >
> >>> and how can it be guaranteed that address is not reserved by the
> platform firmware?
> >> I don't think there is a fool proof method right now, just
heuristics
> >> However freeing ACPI would avoid some of the potential problems.
> >>
> >>>> Also on other systems the ACPI tables are not
> >>>> exactly at the end but in the middle of the memory map and for
some
> applications
> >>>> it might be better to have a lot of physical continuous memory.
> >>>>
> >>>> So are there any plans to free the BIOS supplied ACPI tables
after
> parsing
> >>>> or is there some obstacle to that that I'm missing?
> >>> As Alexey wrote, he and Bob have already deleted the kernel's new
copy
> >>> of the tables in favor of using them 'in place'.
> >>>
> >>> I guess I'm not clear on the requirement here.
> >>> If we were to alter that plan to make a kernel copy -- and release
the
> original BIOS memory --
> >>> assuming it is marked such that we can release it -- how do we
know
> that
> >>> we are not dropping the new copy someplace that kexec doesn't want
it?
> >> There are other allocations anyways and the allocators tend to
cluster,
> so one would
> >> assume it ends up being ok. If there are conflicts they can be
handled
> in
> >> one single place in Linux. But Linux can't affect the BIOS' choice
of
> table
> >> placement.
> >>
> >> Also I suspect the kernel can store it more efficiently in memory.
When
> the tables
> >> are reserved in memory they will be always rounded up/down to page
> boundaries,
> >> while a kernel allocation can fit it better. At least for some of
them
> (like fadt)
> >> the kernel seems to use globals already too, so the original
mapping
> wouldn't be
> >> needed.
> >
> > This  trade-off may not be risk-free.
> > I expect that if Windows tests that the BIOS marks the region
properly
> > and frees it, then Linux will be able to also.  Otherwise Linux will
> fight
> > a BIOS battle it can't win w/o Windows acting as a BIOS validation
test
> for us.
> 
> Actually FACS table has a global_lock in it (which the BIOS writes
too),
> so it is not movable,
> and as all tables are laid contiguously in physical memory, moving
some
> and
> leaving FACS is not an option.
> 
> Regards,
> 	Alex.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Freeing ACPI tables after parsing

[Andi Kleen]

On Tuesday 22 August 2006 22:28, Moore, Robert wrote:
> > Actually FACS table has a global_lock in it (which the BIOS writes
> too),
> > so it is not movable,
> > and as all tables are laid contiguously in physical memory, moving
> some
> > and
> > leaving FACS is not an option.
> 
> This is a very good point. The Global_Lock field of the FACS is not a
> pointer to the global lock, it is the actual memory location of the
> lock. Therefore, the FACS can only be mapped, it cannot be copied.

Ok.  I will fix the e820.h comments then because they're wrong.

-Andi