> kernel absolutely should not care much about SMBIOS(DMI info),
> AFAIK, every BIOS vendor did not fill accurate info in SMBIOS,
> mostly only on demand when OEMs required SMBIOS to report some
> specific info.
> furthermore, SMBIOS is so old and benifit nobody(in my personal
> opinion), so maybe
在 2013-01-18五的 16:08 +0800，Tang Chen写道：
> On 01/18/2013 03:38 PM, Yasuaki Ishimatsu wrote:
> > 2013/01/18 15:25, H. Peter Anvin wrote:
> >> We already do DMI parsing in the kernel...
> >
> > Thank you for giving the infomation.
> >
> > Is your mention /sys/firmware/dmi/entries?
> >
> > If so, my
On 01/18/2013 03:38 PM, Yasuaki Ishimatsu wrote:
2013/01/18 15:25, H. Peter Anvin wrote:
We already do DMI parsing in the kernel...
Thank you for giving the infomation.
Is your mention /sys/firmware/dmi/entries?
If so, my box does not have memory information.
My box has only type 0, 1, 2,
On 01/18/2013 03:38 PM, Yasuaki Ishimatsu wrote:
2013/01/18 15:25, H. Peter Anvin wrote:
We already do DMI parsing in the kernel...
Thank you for giving the infomation.
Is your mention /sys/firmware/dmi/entries?
If so, my box does not have memory information.
My box has only type 0, 1, 2,
在 2013-01-18五的 16:08 +0800，Tang Chen写道：
On 01/18/2013 03:38 PM, Yasuaki Ishimatsu wrote:
2013/01/18 15:25, H. Peter Anvin wrote:
We already do DMI parsing in the kernel...
Thank you for giving the infomation.
Is your mention /sys/firmware/dmi/entries?
If so, my box does not have
kernel absolutely should not care much about SMBIOS(DMI info),
AFAIK, every BIOS vendor did not fill accurate info in SMBIOS,
mostly only on demand when OEMs required SMBIOS to report some
specific info.
furthermore, SMBIOS is so old and benifit nobody(in my personal
opinion), so maybe let's
2013/01/18 15:25, H. Peter Anvin wrote:
We already do DMI parsing in the kernel...
Thank you for giving the infomation.
Is your mention /sys/firmware/dmi/entries?
If so, my box does not have memory information.
My box has only type 0, 1, 2, 3, 4, 7, 8, 9, 38, 127 in DMI.
At least, my box
We already do DMI parsing in the kernel...
Yasuaki Ishimatsu wrote:
>2013/01/18 5:28, KOSAKI Motohiro wrote:
>> On 1/17/2013 11:30 AM, Luck, Tony wrote:
2. If the user *does* care which nodes are movable, then the user
>needs
to be able to specify that *in a way that makes sense to
2013/01/18 5:28, KOSAKI Motohiro wrote:
On 1/17/2013 11:30 AM, Luck, Tony wrote:
2. If the user *does* care which nodes are movable, then the user needs
to be able to specify that *in a way that makes sense to the user*.
This may mean involving the DMI information as well as SRAT in order to
On 1/17/2013 11:30 AM, Luck, Tony wrote:
>> 2. If the user *does* care which nodes are movable, then the user needs
>> to be able to specify that *in a way that makes sense to the user*.
>> This may mean involving the DMI information as well as SRAT in order to
>> get "silk screen" type
On 1/16/2013 6:00 PM, H. Peter Anvin wrote:
> On 01/16/2013 02:01 PM, KOSAKI Motohiro wrote:
>
> Things I'm wondering:
>
> - is there *really* a case for retaining the boot option if/when
>SRAT support is available?
Yes. If SRAT support is available, all memory
On 1/16/2013 8:49 PM, Tang Chen wrote:
> On 01/17/2013 06:52 AM, H. Peter Anvin wrote:
>> On 01/16/2013 01:29 PM, Andrew Morton wrote:
Yes. If SRAT support is available, all memory which enabled hotpluggable
bit are managed by ZONEMOVABLE. But performance degradation may
occur
> 2. If the user *does* care which nodes are movable, then the user needs
> to be able to specify that *in a way that makes sense to the user*.
> This may mean involving the DMI information as well as SRAT in order to
> get "silk screen" type information out.
One reason they might care would
2. If the user *does* care which nodes are movable, then the user needs
to be able to specify that *in a way that makes sense to the user*.
This may mean involving the DMI information as well as SRAT in order to
get silk screen type information out.
One reason they might care would be
On 1/16/2013 8:49 PM, Tang Chen wrote:
On 01/17/2013 06:52 AM, H. Peter Anvin wrote:
On 01/16/2013 01:29 PM, Andrew Morton wrote:
Yes. If SRAT support is available, all memory which enabled hotpluggable
bit are managed by ZONEMOVABLE. But performance degradation may
occur by NUMA because we
On 1/16/2013 6:00 PM, H. Peter Anvin wrote:
On 01/16/2013 02:01 PM, KOSAKI Motohiro wrote:
Things I'm wondering:
- is there *really* a case for retaining the boot option if/when
SRAT support is available?
Yes. If SRAT support is available, all memory which enabled hotpluggable
bit are
On 1/17/2013 11:30 AM, Luck, Tony wrote:
2. If the user *does* care which nodes are movable, then the user needs
to be able to specify that *in a way that makes sense to the user*.
This may mean involving the DMI information as well as SRAT in order to
get silk screen type information out.
2013/01/18 5:28, KOSAKI Motohiro wrote:
On 1/17/2013 11:30 AM, Luck, Tony wrote:
2. If the user *does* care which nodes are movable, then the user needs
to be able to specify that *in a way that makes sense to the user*.
This may mean involving the DMI information as well as SRAT in order to
We already do DMI parsing in the kernel...
Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com wrote:
2013/01/18 5:28, KOSAKI Motohiro wrote:
On 1/17/2013 11:30 AM, Luck, Tony wrote:
2. If the user *does* care which nodes are movable, then the user
needs
to be able to specify that *in a way that
2013/01/18 15:25, H. Peter Anvin wrote:
We already do DMI parsing in the kernel...
Thank you for giving the infomation.
Is your mention /sys/firmware/dmi/entries?
If so, my box does not have memory information.
My box has only type 0, 1, 2, 3, 4, 7, 8, 9, 38, 127 in DMI.
At least, my box
On 01/16/2013 09:08 PM, Yasuaki Ishimatsu wrote:
I thought about the method of specifying the node. But I think
this method is inconvenience. Node number is decided by OS.
So the number is changed easily.
for example:
o exmaple 1
System has 3 nodes:
node0, node1, node2
When user
2013/01/17 7:52, H. Peter Anvin wrote:
On 01/16/2013 01:29 PM, Andrew Morton wrote:
Yes. If SRAT support is available, all memory which enabled hotpluggable
bit are managed by ZONEMOVABLE. But performance degradation may
occur by NUMA because we can only allocate anonymous page and page-cache
On 01/17/2013 06:52 AM, H. Peter Anvin wrote:
On 01/16/2013 01:29 PM, Andrew Morton wrote:
Yes. If SRAT support is available, all memory which enabled hotpluggable
bit are managed by ZONEMOVABLE. But performance degradation may
occur by NUMA because we can only allocate anonymous page and
On 01/16/2013 02:01 PM, KOSAKI Motohiro wrote:
Things I'm wondering:
- is there *really* a case for retaining the boot option if/when
SRAT support is available?
>>>
>>> Yes. If SRAT support is available, all memory which enabled hotpluggable
>>> bit are managed by
On 01/16/2013 01:29 PM, Andrew Morton wrote:
>>
>> Yes. If SRAT support is available, all memory which enabled hotpluggable
>> bit are managed by ZONEMOVABLE. But performance degradation may
>> occur by NUMA because we can only allocate anonymous page and page-cache
>> from these memory.
>>
>> In
On 1/16/2013 4:29 PM, Andrew Morton wrote:
> On Wed, 16 Jan 2013 15:25:44 +0900
> Yasuaki Ishimatsu wrote:
>
>>>
>>> Things I'm wondering:
>>>
>>> - is there *really* a case for retaining the boot option if/when
>>>SRAT support is available?
>>
>> Yes. If SRAT support is available, all
On Wed, 16 Jan 2013 15:25:44 +0900
Yasuaki Ishimatsu wrote:
> >
> > Things I'm wondering:
> >
> > - is there *really* a case for retaining the boot option if/when
> >SRAT support is available?
>
> Yes. If SRAT support is available, all memory which enabled hotpluggable
> bit are managed by
On Wed, 16 Jan 2013 15:25:44 +0900
Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com wrote:
Things I'm wondering:
- is there *really* a case for retaining the boot option if/when
SRAT support is available?
Yes. If SRAT support is available, all memory which enabled hotpluggable
On 1/16/2013 4:29 PM, Andrew Morton wrote:
On Wed, 16 Jan 2013 15:25:44 +0900
Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com wrote:
Things I'm wondering:
- is there *really* a case for retaining the boot option if/when
SRAT support is available?
Yes. If SRAT support is available,
On 01/16/2013 01:29 PM, Andrew Morton wrote:
Yes. If SRAT support is available, all memory which enabled hotpluggable
bit are managed by ZONEMOVABLE. But performance degradation may
occur by NUMA because we can only allocate anonymous page and page-cache
from these memory.
In this case, if
On 01/16/2013 02:01 PM, KOSAKI Motohiro wrote:
Things I'm wondering:
- is there *really* a case for retaining the boot option if/when
SRAT support is available?
Yes. If SRAT support is available, all memory which enabled hotpluggable
bit are managed by ZONEMOVABLE. But performance
On 01/17/2013 06:52 AM, H. Peter Anvin wrote:
On 01/16/2013 01:29 PM, Andrew Morton wrote:
Yes. If SRAT support is available, all memory which enabled hotpluggable
bit are managed by ZONEMOVABLE. But performance degradation may
occur by NUMA because we can only allocate anonymous page and
2013/01/17 7:52, H. Peter Anvin wrote:
On 01/16/2013 01:29 PM, Andrew Morton wrote:
Yes. If SRAT support is available, all memory which enabled hotpluggable
bit are managed by ZONEMOVABLE. But performance degradation may
occur by NUMA because we can only allocate anonymous page and page-cache
On 01/16/2013 09:08 PM, Yasuaki Ishimatsu wrote:
I thought about the method of specifying the node. But I think
this method is inconvenience. Node number is decided by OS.
So the number is changed easily.
for example:
o exmaple 1
System has 3 nodes:
node0, node1, node2
When user
2013/01/15 7:46, Andrew Morton wrote:
On Mon, 14 Jan 2013 22:41:03 +
"Luck, Tony" wrote:
hm, why. Obviously SRAT support will improve things, but is it
actually unusable/unuseful with the command line configuration?
Users will want to set these moveable zones along node boundaries
(the
2013/01/15 7:46, Andrew Morton wrote:
On Mon, 14 Jan 2013 22:41:03 +
Luck, Tony tony.l...@intel.com wrote:
hm, why. Obviously SRAT support will improve things, but is it
actually unusable/unuseful with the command line configuration?
Users will want to set these moveable zones along
>>
>> I don't think so because user can easily get raw address by kernel
>> message in x86.
>>
Which will fail if on some subsequent boot a DIMM fails BIST and is removed
from the memory map by the BIOS which will then change all the mode boundaries
for those above the failed DIMM.
-Tony--
That *is* user abuse.
Yasuaki Ishimatsu wrote:
>2013/01/15 7:41, Luck, Tony wrote:
>>> hm, why. Obviously SRAT support will improve things, but is it
>>> actually unusable/unuseful with the command line configuration?
>>
>
>> Users will want to set these moveable zones along node boundaries
>>
2013/01/15 7:41, Luck, Tony wrote:
hm, why. Obviously SRAT support will improve things, but is it
actually unusable/unuseful with the command line configuration?
Users will want to set these moveable zones along node boundaries
(the whole purpose is to be able to remove a node by making
On Mon, 2013-01-14 at 14:34 -0800, Andrew Morton wrote:
> On Mon, 14 Jan 2013 09:31:33 -0800
> "H. Peter Anvin" wrote:
>
> > On 01/14/2013 01:15 AM, Tang Chen wrote:
> > >
> > > For now, users can disable this functionality by not specifying the boot
> > > option.
> > > Later, we will post SRAT
> hm, why. Obviously SRAT support will improve things, but is it
> actually unusable/unuseful with the command line configuration?
Users will want to set these moveable zones along node boundaries
(the whole purpose is to be able to remove a node by making sure
the kernel won't allocate anything
On Mon, 14 Jan 2013 09:31:33 -0800
"H. Peter Anvin" wrote:
> On 01/14/2013 01:15 AM, Tang Chen wrote:
> >
> > For now, users can disable this functionality by not specifying the boot
> > option.
> > Later, we will post SRAT support, and add another option value
> > "movablecore_map=acpi"
> >
On 01/14/2013 01:15 AM, Tang Chen wrote:
For now, users can disable this functionality by not specifying the boot option.
Later, we will post SRAT support, and add another option value
"movablecore_map=acpi"
to using SRAT.
I still think the option "movablecore_map" is uglier than hell.
Hi Andrew, all,
Here is movablecore_map patch-set based on 3.8-rc3.
During the implementation of SRAT support, we met a problem.
In setup_arch(), we have the following call series:
1) memblock is ready;
2) some functions use memblock to allocate memory;
3) parse ACPI tables, such as SRAT.
Hi Andrew, all,
Here is movablecore_map patch-set based on 3.8-rc3.
During the implementation of SRAT support, we met a problem.
In setup_arch(), we have the following call series:
1) memblock is ready;
2) some functions use memblock to allocate memory;
3) parse ACPI tables, such as SRAT.
On 01/14/2013 01:15 AM, Tang Chen wrote:
For now, users can disable this functionality by not specifying the boot option.
Later, we will post SRAT support, and add another option value
movablecore_map=acpi
to using SRAT.
I still think the option movablecore_map is uglier than hell. core
On Mon, 14 Jan 2013 09:31:33 -0800
H. Peter Anvin h...@zytor.com wrote:
On 01/14/2013 01:15 AM, Tang Chen wrote:
For now, users can disable this functionality by not specifying the boot
option.
Later, we will post SRAT support, and add another option value
movablecore_map=acpi
to
hm, why. Obviously SRAT support will improve things, but is it
actually unusable/unuseful with the command line configuration?
Users will want to set these moveable zones along node boundaries
(the whole purpose is to be able to remove a node by making sure
the kernel won't allocate anything
On Mon, 2013-01-14 at 14:34 -0800, Andrew Morton wrote:
On Mon, 14 Jan 2013 09:31:33 -0800
H. Peter Anvin h...@zytor.com wrote:
On 01/14/2013 01:15 AM, Tang Chen wrote:
For now, users can disable this functionality by not specifying the boot
option.
Later, we will post SRAT
2013/01/15 7:41, Luck, Tony wrote:
hm, why. Obviously SRAT support will improve things, but is it
actually unusable/unuseful with the command line configuration?
Users will want to set these moveable zones along node boundaries
(the whole purpose is to be able to remove a node by making
That *is* user abuse.
Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com wrote:
2013/01/15 7:41, Luck, Tony wrote:
hm, why. Obviously SRAT support will improve things, but is it
actually unusable/unuseful with the command line configuration?
Users will want to set these moveable zones along
I don't think so because user can easily get raw address by kernel
message in x86.
Which will fail if on some subsequent boot a DIMM fails BIST and is removed
from the memory map by the BIOS which will then change all the mode boundaries
for those above the failed DIMM.
-Tony--
To
52 matches
Mail list logo
