* Why we echo a invalid start_address_of_new_memory succeeded ?
@ 2014-06-20 7:06 Zhang Zhen
2014-06-20 10:30 ` David Rientjes
0 siblings, 1 reply; 4+ messages in thread
From: Zhang Zhen @ 2014-06-20 7:06 UTC (permalink / raw)
To: David Rientjes; +Cc: wangnan0, xiaofeng.yan, linux-mm
Hi,
I am testing mem-hotplug on a qemu virtual machine. I executed the following command
to notify memory hot-add event by hand.
% echo start_address_of_new_memory > /sys/devices/system/memory/probe
To a different start_address_of_new_memory I got different results.
The results are as follows:
MBSC-x86_64 /sys/devices/system/memory # ls
block_size_bytes memory2 memory5 power
memory0 memory3 memory6 probe
memory1 memory4 memory7 uevent
MBSC-x86_64 /sys/devices/system/memory # echo 0x70000000 > probe
MBSC-x86_64 /sys/devices/system/memory # echo 0x78000000 > probe
-sh: echo: write error: File exists
MBSC-x86_64 /sys/devices/system/memory # echo 0x80000000 > probe
-sh: echo: write error: File exists
MBSC-x86_64 /sys/devices/system/memory # echo 0x88000000 > probe
-sh: echo: write error: File exists
MBSC-x86_64 /sys/devices/system/memory # echo 0x8f000000 > probe
-sh: echo: write error: Invalid argument
MBSC-x86_64 /sys/devices/system/memory # echo 0x90000000 > probe
-sh: echo: write error: File exists
MBSC-x86_64 /sys/devices/system/memory # echo 0xff0000000 > probe
MBSC-x86_64 /sys/devices/system/memory # ls
block_size_bytes memory2 memory510 probe
memory0 memory3 memory6 uevent
memory1 memory4 memory7
memory14 memory5 power
MBSC-x86_64 /sys/devices/system/memory # echo 0xfff0000000 > probe
MBSC-x86_64 /sys/devices/system/memory # ls
block_size_bytes memory2 memory510 power
memory0 memory3 memory6 probe
memory1 memory4 memory7 uevent
memory14 memory5 memory8190
The qemu virtual machine's physical memory size is 2048M, and the boot memory is 1024M.
MBSC-x86_64 / # cat /proc/meminfo
MemTotal: 1018356 kB
MBSC-x86_64 / # cat /sys/devices/system/memory/block_size_bytes
8000000
Three questions:
1. The machine's physical memory size is 2048M, why echo 0x78000000 as the start_address_of_new_memory failed ?
2. Why echo 0x8f000000 as the start_address_of_new_memory, the error message is different ?
3. Why echo 0xfff0000000 as the start_address_of_new_memory succeeded ? 0xfff0000000 has exceeded the machine's physical memory size.
Best regards!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Why we echo a invalid start_address_of_new_memory succeeded ?
2014-06-20 7:06 Why we echo a invalid start_address_of_new_memory succeeded ? Zhang Zhen
@ 2014-06-20 10:30 ` David Rientjes
2014-06-23 10:50 ` Zhang Zhen
0 siblings, 1 reply; 4+ messages in thread
From: David Rientjes @ 2014-06-20 10:30 UTC (permalink / raw)
To: Zhang Zhen; +Cc: wangnan0, xiaofeng.yan, linux-mm
On Fri, 20 Jun 2014, Zhang Zhen wrote:
> Hi,
>
> I am testing mem-hotplug on a qemu virtual machine. I executed the following command
> to notify memory hot-add event by hand.
>
> % echo start_address_of_new_memory > /sys/devices/system/memory/probe
>
> To a different start_address_of_new_memory I got different results.
> The results are as follows:
>
> MBSC-x86_64 /sys/devices/system/memory # ls
> block_size_bytes memory2 memory5 power
> memory0 memory3 memory6 probe
> memory1 memory4 memory7 uevent
> MBSC-x86_64 /sys/devices/system/memory # echo 0x70000000 > probe
Since block_size_bytes is 0x8000000 == 128MB, this is 0x70000000 /
0x8000000 = section number 14. Successfully hot added. Presumably you're
reporting that there is no physical memory there, so this would default to
the online node of the first memory block, probably node 0.
> MBSC-x86_64 /sys/devices/system/memory # echo 0x78000000 > probe
> -sh: echo: write error: File exists
EEXIST gets returned when the resource already exists, mostly likely
system RAM or reserved memory as reported by your BIOS. You report this
is a 2GB machine, no reason to believe memory at 1920MB isn't already
online (including reserved).
> MBSC-x86_64 /sys/devices/system/memory # echo 0x80000000 > probe
> -sh: echo: write error: File exists
> MBSC-x86_64 /sys/devices/system/memory # echo 0x88000000 > probe
> -sh: echo: write error: File exists
Same.
> MBSC-x86_64 /sys/devices/system/memory # echo 0x8f000000 > probe
> -sh: echo: write error: Invalid argument
Returns EINVAL because it's not a multiple of block_size_bytes, it's not
aligned properly.
> MBSC-x86_64 /sys/devices/system/memory # echo 0x90000000 > probe
> -sh: echo: write error: File exists
See above, the resoure already exists. Check your e820 your dmesg, which
is missing from this report, to determine what already exists and may be
already online or reserved.
> MBSC-x86_64 /sys/devices/system/memory # echo 0xff0000000 > probe
0xff0000000 / 0x8000000 is section 510, successfully onlined.
> MBSC-x86_64 /sys/devices/system/memory # ls
> block_size_bytes memory2 memory510 probe
> memory0 memory3 memory6 uevent
> memory1 memory4 memory7
> memory14 memory5 power
Looks good, you onlined sections 14 and 510 above.
> MBSC-x86_64 /sys/devices/system/memory # echo 0xfff0000000 > probe
Same for section 8190.
> MBSC-x86_64 /sys/devices/system/memory # ls
> block_size_bytes memory2 memory510 power
> memory0 memory3 memory6 probe
> memory1 memory4 memory7 uevent
> memory14 memory5 memory8190
>
Confirmed it's onlined.
> The qemu virtual machine's physical memory size is 2048M, and the boot memory is 1024M.
>
> MBSC-x86_64 / # cat /proc/meminfo
> MemTotal: 1018356 kB
> MBSC-x86_64 / # cat /sys/devices/system/memory/block_size_bytes
> 8000000
>
That's irrelevant, you've explicitly onlined memory that doesn't exist.
Not sure why you're using the probe interface unless you need it for x86,
is ACPI not registering it correctly?
> Three questions:
> 1. The machine's physical memory size is 2048M, why echo 0x78000000 as the start_address_of_new_memory failed ?
>
Copy your e820 map from your dmesg, it's probably reserved or already
online, this is lower than 2048M.
> 2. Why echo 0x8f000000 as the start_address_of_new_memory, the error message is different ?
>
Not properly aligned to block_size_bytes. It's a nuance, but
block_size_bytes is exported in hex, not decimal.
> 3. Why echo 0xfff0000000 as the start_address_of_new_memory succeeded ? 0xfff0000000 has exceeded the machine's physical memory size.
>
You're telling the kernel differently.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Why we echo a invalid start_address_of_new_memory succeeded ?
2014-06-20 10:30 ` David Rientjes
@ 2014-06-23 10:50 ` Zhang Zhen
2014-06-23 11:18 ` Zhang Zhen
0 siblings, 1 reply; 4+ messages in thread
From: Zhang Zhen @ 2014-06-23 10:50 UTC (permalink / raw)
To: David Rientjes; +Cc: wangnan0, xiaofeng.yan, linux-mm
On 2014/6/20 18:30, David Rientjes wrote:
> On Fri, 20 Jun 2014, Zhang Zhen wrote:
>
>> Hi,
>>
>> I am testing mem-hotplug on a qemu virtual machine. I executed the following command
>> to notify memory hot-add event by hand.
>>
>> % echo start_address_of_new_memory > /sys/devices/system/memory/probe
>>
>> To a different start_address_of_new_memory I got different results.
>> The results are as follows:
>>
>> MBSC-x86_64 /sys/devices/system/memory # ls
>> block_size_bytes memory2 memory5 power
>> memory0 memory3 memory6 probe
>> memory1 memory4 memory7 uevent
>> MBSC-x86_64 /sys/devices/system/memory # echo 0x70000000 > probe
>
> Since block_size_bytes is 0x8000000 == 128MB, this is 0x70000000 /
> 0x8000000 = section number 14. Successfully hot added. Presumably you're
> reporting that there is no physical memory there, so this would default to
> the online node of the first memory block, probably node 0.
>
>> MBSC-x86_64 /sys/devices/system/memory # echo 0x78000000 > probe
>> -sh: echo: write error: File exists
>
> EEXIST gets returned when the resource already exists, mostly likely
> system RAM or reserved memory as reported by your BIOS. You report this
> is a 2GB machine, no reason to believe memory at 1920MB isn't already
> online (including reserved).
>
>> MBSC-x86_64 /sys/devices/system/memory # echo 0x80000000 > probe
>> -sh: echo: write error: File exists
>> MBSC-x86_64 /sys/devices/system/memory # echo 0x88000000 > probe
>> -sh: echo: write error: File exists
>
> Same.
>
>> MBSC-x86_64 /sys/devices/system/memory # echo 0x8f000000 > probe
>> -sh: echo: write error: Invalid argument
>
> Returns EINVAL because it's not a multiple of block_size_bytes, it's not
> aligned properly.
>
>> MBSC-x86_64 /sys/devices/system/memory # echo 0x90000000 > probe
>> -sh: echo: write error: File exists
>
> See above, the resoure already exists. Check your e820 your dmesg, which
> is missing from this report, to determine what already exists and may be
> already online or reserved.
>
>> MBSC-x86_64 /sys/devices/system/memory # echo 0xff0000000 > probe
>
> 0xff0000000 / 0x8000000 is section 510, successfully onlined.
>
>> MBSC-x86_64 /sys/devices/system/memory # ls
>> block_size_bytes memory2 memory510 probe
>> memory0 memory3 memory6 uevent
>> memory1 memory4 memory7
>> memory14 memory5 power
>
> Looks good, you onlined sections 14 and 510 above.
>
>> MBSC-x86_64 /sys/devices/system/memory # echo 0xfff0000000 > probe
>
> Same for section 8190.
>
>> MBSC-x86_64 /sys/devices/system/memory # ls
>> block_size_bytes memory2 memory510 power
>> memory0 memory3 memory6 probe
>> memory1 memory4 memory7 uevent
>> memory14 memory5 memory8190
>>
>
> Confirmed it's onlined.
>
>> The qemu virtual machine's physical memory size is 2048M, and the boot memory is 1024M.
>>
>> MBSC-x86_64 / # cat /proc/meminfo
>> MemTotal: 1018356 kB
>> MBSC-x86_64 / # cat /sys/devices/system/memory/block_size_bytes
>> 8000000
>>
>
> That's irrelevant, you've explicitly onlined memory that doesn't exist.
> Not sure why you're using the probe interface unless you need it for x86,
> is ACPI not registering it correctly?
>
>> Three questions:
>> 1. The machine's physical memory size is 2048M, why echo 0x78000000 as the start_address_of_new_memory failed ?
>>
>
> Copy your e820 map from your dmesg, it's probably reserved or already
> online, this is lower than 2048M.
>
Hi David,
You are right, if we echo 0x78000000 as the start_address_of_new_memory, the end_address_of_new_memory is exceeded
the usable range.
Thank you for your comments.
My e820 map as follows:
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007fffdfff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007fffe000-0x000000007fffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[ 0.000000] e820: remove [mem 0x40000000-0xfffffffffffffffe] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] e820: user-defined physical RAM map:
[ 0.000000] user: [mem 0x0000000000000000-0x000000000009fbff] usable
[ 0.000000] user: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[ 0.000000] user: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[ 0.000000] user: [mem 0x0000000000100000-0x000000003fffffff] usable
[ 0.000000] user: [mem 0x000000007fffe000-0x000000007fffffff] reserved
[ 0.000000] user: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
>> 2. Why echo 0x8f000000 as the start_address_of_new_memory, the error message is different ?
>>
>
> Not properly aligned to block_size_bytes. It's a nuance, but
> block_size_bytes is exported in hex, not decimal.
You are right, it's not properly aligned to block_size_bytes. I have made a mistake.
>
>> 3. Why echo 0xfff0000000 as the start_address_of_new_memory succeeded ? 0xfff0000000 has exceeded the machine's physical memory size.
>>
>
> You're telling the kernel differently.
>
I'm not clearly here, 0xfff0000000 is exceeded the usable range [mem 0x0000000000100000-0x000000007fffdfff] usable.
So i think here should return "File exists", but it succeeded.
Is it properly ?
Best regards!
> .
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Why we echo a invalid start_address_of_new_memory succeeded ?
2014-06-23 10:50 ` Zhang Zhen
@ 2014-06-23 11:18 ` Zhang Zhen
0 siblings, 0 replies; 4+ messages in thread
From: Zhang Zhen @ 2014-06-23 11:18 UTC (permalink / raw)
To: David Rientjes; +Cc: wangnan0, xiaofeng.yan, linux-mm
On 2014/6/23 18:50, Zhang Zhen wrote:
> On 2014/6/20 18:30, David Rientjes wrote:
>> On Fri, 20 Jun 2014, Zhang Zhen wrote:
>>
>>> Hi,
>>>
>>> I am testing mem-hotplug on a qemu virtual machine. I executed the following command
>>> to notify memory hot-add event by hand.
>>>
>>> % echo start_address_of_new_memory > /sys/devices/system/memory/probe
>>>
>>> To a different start_address_of_new_memory I got different results.
>>> The results are as follows:
>>>
>>> MBSC-x86_64 /sys/devices/system/memory # ls
>>> block_size_bytes memory2 memory5 power
>>> memory0 memory3 memory6 probe
>>> memory1 memory4 memory7 uevent
>>> MBSC-x86_64 /sys/devices/system/memory # echo 0x70000000 > probe
>>
>> Since block_size_bytes is 0x8000000 == 128MB, this is 0x70000000 /
>> 0x8000000 = section number 14. Successfully hot added. Presumably you're
>> reporting that there is no physical memory there, so this would default to
>> the online node of the first memory block, probably node 0.
>>
>>> MBSC-x86_64 /sys/devices/system/memory # echo 0x78000000 > probe
>>> -sh: echo: write error: File exists
>>
>> EEXIST gets returned when the resource already exists, mostly likely
>> system RAM or reserved memory as reported by your BIOS. You report this
>> is a 2GB machine, no reason to believe memory at 1920MB isn't already
>> online (including reserved).
>>
>>> MBSC-x86_64 /sys/devices/system/memory # echo 0x80000000 > probe
>>> -sh: echo: write error: File exists
>>> MBSC-x86_64 /sys/devices/system/memory # echo 0x88000000 > probe
>>> -sh: echo: write error: File exists
>>
>> Same.
>>
>>> MBSC-x86_64 /sys/devices/system/memory # echo 0x8f000000 > probe
>>> -sh: echo: write error: Invalid argument
>>
>> Returns EINVAL because it's not a multiple of block_size_bytes, it's not
>> aligned properly.
>>
>>> MBSC-x86_64 /sys/devices/system/memory # echo 0x90000000 > probe
>>> -sh: echo: write error: File exists
>>
>> See above, the resoure already exists. Check your e820 your dmesg, which
>> is missing from this report, to determine what already exists and may be
>> already online or reserved.
>>
>>> MBSC-x86_64 /sys/devices/system/memory # echo 0xff0000000 > probe
>>
>> 0xff0000000 / 0x8000000 is section 510, successfully onlined.
>>
>>> MBSC-x86_64 /sys/devices/system/memory # ls
>>> block_size_bytes memory2 memory510 probe
>>> memory0 memory3 memory6 uevent
>>> memory1 memory4 memory7
>>> memory14 memory5 power
>>
>> Looks good, you onlined sections 14 and 510 above.
>>
>>> MBSC-x86_64 /sys/devices/system/memory # echo 0xfff0000000 > probe
>>
>> Same for section 8190.
>>
>>> MBSC-x86_64 /sys/devices/system/memory # ls
>>> block_size_bytes memory2 memory510 power
>>> memory0 memory3 memory6 probe
>>> memory1 memory4 memory7 uevent
>>> memory14 memory5 memory8190
>>>
>>
>> Confirmed it's onlined.
>>
>>> The qemu virtual machine's physical memory size is 2048M, and the boot memory is 1024M.
>>>
>>> MBSC-x86_64 / # cat /proc/meminfo
>>> MemTotal: 1018356 kB
>>> MBSC-x86_64 / # cat /sys/devices/system/memory/block_size_bytes
>>> 8000000
>>>
>>
>> That's irrelevant, you've explicitly onlined memory that doesn't exist.
>> Not sure why you're using the probe interface unless you need it for x86,
>> is ACPI not registering it correctly?
>>
>>> Three questions:
>>> 1. The machine's physical memory size is 2048M, why echo 0x78000000 as the start_address_of_new_memory failed ?
>>>
>>
>> Copy your e820 map from your dmesg, it's probably reserved or already
>> online, this is lower than 2048M.
>>
>
> Hi David,
>
> You are right, if we echo 0x78000000 as the start_address_of_new_memory, the end_address_of_new_memory is exceeded
> the usable range.
> Thank you for your comments.
>
> My e820 map as follows:
>
> [ 0.000000] e820: BIOS-provided physical RAM map:
> [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
> [ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007fffdfff] usable
> [ 0.000000] BIOS-e820: [mem 0x000000007fffe000-0x000000007fffffff] reserved
> [ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
> [ 0.000000] e820: remove [mem 0x40000000-0xfffffffffffffffe] usable
> [ 0.000000] NX (Execute Disable) protection: active
> [ 0.000000] e820: user-defined physical RAM map:
> [ 0.000000] user: [mem 0x0000000000000000-0x000000000009fbff] usable
> [ 0.000000] user: [mem 0x000000000009fc00-0x000000000009ffff] reserved
> [ 0.000000] user: [mem 0x00000000000f0000-0x00000000000fffff] reserved
> [ 0.000000] user: [mem 0x0000000000100000-0x000000003fffffff] usable
> [ 0.000000] user: [mem 0x000000007fffe000-0x000000007fffffff] reserved
> [ 0.000000] user: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
>
>>> 2. Why echo 0x8f000000 as the start_address_of_new_memory, the error message is different ?
>>>
>>
>> Not properly aligned to block_size_bytes. It's a nuance, but
>> block_size_bytes is exported in hex, not decimal.
>
> You are right, it's not properly aligned to block_size_bytes. I have made a mistake.
>
>>
>>> 3. Why echo 0xfff0000000 as the start_address_of_new_memory succeeded ? 0xfff0000000 has exceeded the machine's physical memory size.
>>>
>>
>> You're telling the kernel differently.
>>
>
> I'm not clearly here, 0xfff0000000 is exceeded the usable range [mem 0x0000000000100000-0x000000007fffdfff] usable.
> So i think here should return "File exists", but it succeeded.
>
> Is it properly ?
>
I got it, the address's validity should be guaranteed by me. Right?
Thank you.
> Best regards!
>
>> .
>>
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
> .
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-06-23 11:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-20 7:06 Why we echo a invalid start_address_of_new_memory succeeded ? Zhang Zhen
2014-06-20 10:30 ` David Rientjes
2014-06-23 10:50 ` Zhang Zhen
2014-06-23 11:18 ` Zhang Zhen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox