> 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 bo
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, 3,
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 cann
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 the
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
get
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 informat
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 whi
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 b
> 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 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 remo
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
f
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 page-
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 ZONEMO
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 t
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 memory
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 Z
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
>>
>> 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--
T
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 sur
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"
> > to
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. "cor
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.
Befor
26 matches
Mail list logo
