On Wed, Aug 14, 2013 at 09:44:19PM -0400, KOSAKI Motohiro wrote:
> >This is doubly idiotic because this is all early boot. Most users
> >don't even have a way to access the debug info if the machine crashes
> >that early. Developement convenience is something that we consider
> >too but,
On Wed, Aug 14, 2013 at 09:38:12PM -0400, KOSAKI Motohiro wrote:
> As you think makes no sense, I also think your position makes no sense. So,
> please
> stop emotional word. That doesn't help discussion progress.
Would you then please stop making nonsense assertions like "the
fundamental rule
(8/14/13 9:33 PM), Tejun Heo wrote:
On Wed, Aug 14, 2013 at 09:21:33PM -0400, Tejun Heo wrote:
Secondly, memory hotplug is now maintained I and kamezawa-san. Then, I much
likely
have a chance to get a hotplug related bug report. For protecting my life, I
don't
want get a false bug claim.
(8/14/13 9:21 PM), Tejun Heo wrote:
Hello, KOSAKI.
On Wed, Aug 14, 2013 at 09:08:22PM -0400, KOSAKI Motohiro wrote:
...
a fallback. Bogus and misguided fallback give a user false relief and they don't
notice their mistake quickly. The answer is, there is the fundamental rule.
We always said,
On Wed, Aug 14, 2013 at 09:21:33PM -0400, Tejun Heo wrote:
> > Secondly, memory hotplug is now maintained I and kamezawa-san. Then, I much
> > likely
> > have a chance to get a hotplug related bug report. For protecting my life,
> > I don't
> > want get a false bug claim. Then, I wouldn't like
Hello, KOSAKI.
On Wed, Aug 14, 2013 at 09:08:22PM -0400, KOSAKI Motohiro wrote:
...
> a fallback. Bogus and misguided fallback give a user false relief and they
> don't
> notice their mistake quickly. The answer is, there is the fundamental rule.
> We always said, "measure your system carefully,
(8/14/13 5:36 PM), Tejun Heo wrote:
> On Wed, Aug 14, 2013 at 05:17:23PM -0400, KOSAKI Motohiro wrote:
>> You haven't explain practical benefit of your opinion. As far as users have
>> no benefit, I'm never agree. Sorry.
>
> Umm... how about being more robust and actually useable to begin with?
>
On Wed, Aug 14, 2013 at 05:17:23PM -0400, KOSAKI Motohiro wrote:
> You haven't explain practical benefit of your opinion. As far as users have
> no benefit, I'm never agree. Sorry.
Umm... how about being more robust and actually useable to begin with?
What's the benefit of panicking? Are you
(8/14/13 4:35 PM), Tejun Heo wrote:
On Wed, Aug 14, 2013 at 04:29:05PM -0400, KOSAKI Motohiro wrote:
Because boot failure have no chance to overlook and better way for practice.
That's an extremely poor excuse. We favor WARNs over BUGs for good
reasons. If a sysadmin cares about hotplug and
On Wed, Aug 14, 2013 at 04:29:05PM -0400, KOSAKI Motohiro wrote:
> Because boot failure have no chance to overlook and better way for practice.
That's an extremely poor excuse. We favor WARNs over BUGs for good
reasons. If a sysadmin cares about hotplug and can't deal with the
system
There are systems which can. They have the ability to remap in hardware.
KOSAKI Motohiro wrote:
>(8/14/13 3:55 PM), Tejun Heo wrote:
>> Hello,
>>
>> On Wed, Aug 14, 2013 at 03:40:31PM -0400, KOSAKI Motohiro wrote:
>>> I don't agree it. Please look at other kernel options. A lot of
>these don't
(8/14/13 3:55 PM), Tejun Heo wrote:
Hello,
On Wed, Aug 14, 2013 at 03:40:31PM -0400, KOSAKI Motohiro wrote:
I don't agree it. Please look at other kernel options. A lot of these don't
follow you. These behave as direction, not advise.
I mean the fallback should be implemented at turning on
Hello,
On Wed, Aug 14, 2013 at 03:40:31PM -0400, KOSAKI Motohiro wrote:
> I don't agree it. Please look at other kernel options. A lot of these don't
> follow you. These behave as direction, not advise.
>
> I mean the fallback should be implemented at turning on default the feature.
Yeah, some
(8/14/13 2:23 PM), Tejun Heo wrote:
Hello,
On Wed, Aug 14, 2013 at 02:15:44PM -0400, KOSAKI Motohiro wrote:
I don't follow this. We need to think why memory hotplug is necessary.
Because system reboot is unacceptable on several critical services. Then,
if someone set wrong boot option, systems
Hello,
On Wed, Aug 14, 2013 at 02:15:44PM -0400, KOSAKI Motohiro wrote:
> I don't follow this. We need to think why memory hotplug is necessary.
> Because system reboot is unacceptable on several critical services. Then,
> if someone set wrong boot option, systems SHOULD fail to boot. At that
(8/12/13 1:23 PM), H. Peter Anvin wrote:
On 08/12/2013 10:01 AM, Tang Chen wrote:
I'm just thinking of a more extreme case. For example, if a machine
has only one node hotpluggable, and the kernel resides in that node.
Then the system has no hotpluggable node.
Yeah, sure, then there's no
(8/12/13 2:07 PM), Tejun Heo wrote:
Hey,
On Tue, Aug 13, 2013 at 01:01:09AM +0800, Tang Chen wrote:
Sorry for the misunderstanding.
I was trying to answer your question: "Why can't the kenrel allocate
hotpluggable memory opportunistic ?".
I've used the wrong word, I was meaning best-effort,
(8/12/13 2:07 PM), Tejun Heo wrote:
Hey,
On Tue, Aug 13, 2013 at 01:01:09AM +0800, Tang Chen wrote:
Sorry for the misunderstanding.
I was trying to answer your question: Why can't the kenrel allocate
hotpluggable memory opportunistic ?.
I've used the wrong word, I was meaning best-effort,
(8/12/13 1:23 PM), H. Peter Anvin wrote:
On 08/12/2013 10:01 AM, Tang Chen wrote:
I'm just thinking of a more extreme case. For example, if a machine
has only one node hotpluggable, and the kernel resides in that node.
Then the system has no hotpluggable node.
Yeah, sure, then there's no
Hello,
On Wed, Aug 14, 2013 at 02:15:44PM -0400, KOSAKI Motohiro wrote:
I don't follow this. We need to think why memory hotplug is necessary.
Because system reboot is unacceptable on several critical services. Then,
if someone set wrong boot option, systems SHOULD fail to boot. At that time,
(8/14/13 2:23 PM), Tejun Heo wrote:
Hello,
On Wed, Aug 14, 2013 at 02:15:44PM -0400, KOSAKI Motohiro wrote:
I don't follow this. We need to think why memory hotplug is necessary.
Because system reboot is unacceptable on several critical services. Then,
if someone set wrong boot option, systems
Hello,
On Wed, Aug 14, 2013 at 03:40:31PM -0400, KOSAKI Motohiro wrote:
I don't agree it. Please look at other kernel options. A lot of these don't
follow you. These behave as direction, not advise.
I mean the fallback should be implemented at turning on default the feature.
Yeah, some
(8/14/13 3:55 PM), Tejun Heo wrote:
Hello,
On Wed, Aug 14, 2013 at 03:40:31PM -0400, KOSAKI Motohiro wrote:
I don't agree it. Please look at other kernel options. A lot of these don't
follow you. These behave as direction, not advise.
I mean the fallback should be implemented at turning on
There are systems which can. They have the ability to remap in hardware.
KOSAKI Motohiro kosaki.motoh...@gmail.com wrote:
(8/14/13 3:55 PM), Tejun Heo wrote:
Hello,
On Wed, Aug 14, 2013 at 03:40:31PM -0400, KOSAKI Motohiro wrote:
I don't agree it. Please look at other kernel options. A lot
On Wed, Aug 14, 2013 at 04:29:05PM -0400, KOSAKI Motohiro wrote:
Because boot failure have no chance to overlook and better way for practice.
That's an extremely poor excuse. We favor WARNs over BUGs for good
reasons. If a sysadmin cares about hotplug and can't deal with the
system
(8/14/13 4:35 PM), Tejun Heo wrote:
On Wed, Aug 14, 2013 at 04:29:05PM -0400, KOSAKI Motohiro wrote:
Because boot failure have no chance to overlook and better way for practice.
That's an extremely poor excuse. We favor WARNs over BUGs for good
reasons. If a sysadmin cares about hotplug and
On Wed, Aug 14, 2013 at 05:17:23PM -0400, KOSAKI Motohiro wrote:
You haven't explain practical benefit of your opinion. As far as users have
no benefit, I'm never agree. Sorry.
Umm... how about being more robust and actually useable to begin with?
What's the benefit of panicking? Are you
(8/14/13 5:36 PM), Tejun Heo wrote:
On Wed, Aug 14, 2013 at 05:17:23PM -0400, KOSAKI Motohiro wrote:
You haven't explain practical benefit of your opinion. As far as users have
no benefit, I'm never agree. Sorry.
Umm... how about being more robust and actually useable to begin with?
What's
Hello, KOSAKI.
On Wed, Aug 14, 2013 at 09:08:22PM -0400, KOSAKI Motohiro wrote:
...
a fallback. Bogus and misguided fallback give a user false relief and they
don't
notice their mistake quickly. The answer is, there is the fundamental rule.
We always said, measure your system carefully, and
On Wed, Aug 14, 2013 at 09:21:33PM -0400, Tejun Heo wrote:
Secondly, memory hotplug is now maintained I and kamezawa-san. Then, I much
likely
have a chance to get a hotplug related bug report. For protecting my life,
I don't
want get a false bug claim. Then, I wouldn't like to aim
(8/14/13 9:21 PM), Tejun Heo wrote:
Hello, KOSAKI.
On Wed, Aug 14, 2013 at 09:08:22PM -0400, KOSAKI Motohiro wrote:
...
a fallback. Bogus and misguided fallback give a user false relief and they don't
notice their mistake quickly. The answer is, there is the fundamental rule.
We always said,
(8/14/13 9:33 PM), Tejun Heo wrote:
On Wed, Aug 14, 2013 at 09:21:33PM -0400, Tejun Heo wrote:
Secondly, memory hotplug is now maintained I and kamezawa-san. Then, I much
likely
have a chance to get a hotplug related bug report. For protecting my life, I
don't
want get a false bug claim.
On Wed, Aug 14, 2013 at 09:38:12PM -0400, KOSAKI Motohiro wrote:
As you think makes no sense, I also think your position makes no sense. So,
please
stop emotional word. That doesn't help discussion progress.
Would you then please stop making nonsense assertions like the
fundamental rule here
On Wed, Aug 14, 2013 at 09:44:19PM -0400, KOSAKI Motohiro wrote:
This is doubly idiotic because this is all early boot. Most users
don't even have a way to access the debug info if the machine crashes
that early. Developement convenience is something that we consider
too but, seriously,
Hello, Tang.
On Tue, Aug 13, 2013 at 05:56:46PM +0800, Tang Chen wrote:
> 1. Introduce a memblock.current_limit_low to limit the lowest address
>that memblock can use.
>
> 2. Make memblock be able to allocate memory from low to high.
>
> 3. Get kernel image address on x86, and set
Hi tj,
When doing the "near kernel memory allocation", I have something
about memblock that I need you to comfirm.
1. First of all, memblock is platform independent. Different platforms
have different ways to store kernel image address. So I don't think
we can obtain the kernel image
On 08/13/2013 12:46 AM, Tejun Heo wrote:
..
* Adding an option to tell the kernel to try to stay away from
hotpluggable nodes is fine. I have no problem with that at all.
* The patchsets upto this point have been somehow trying to reorder
operations shomehow such that *no* memory
Hi tj,
When doing the near kernel memory allocation, I have something
about memblock that I need you to comfirm.
1. First of all, memblock is platform independent. Different platforms
have different ways to store kernel image address. So I don't think
we can obtain the kernel image
Hello, Tang.
On Tue, Aug 13, 2013 at 05:56:46PM +0800, Tang Chen wrote:
1. Introduce a memblock.current_limit_low to limit the lowest address
that memblock can use.
2. Make memblock be able to allocate memory from low to high.
3. Get kernel image address on x86, and set
On 08/13/2013 12:46 AM, Tejun Heo wrote:
..
* Adding an option to tell the kernel to try to stay away from
hotpluggable nodes is fine. I have no problem with that at all.
* The patchsets upto this point have been somehow trying to reorder
operations shomehow such that *no* memory
Hello,
On Tue, Aug 13, 2013 at 02:23:13AM +0800, Tang Chen wrote:
> >* However, we already *know* that the memory the kernel image is
> > occupying won't be removeable. It's highly likely that the amount
> > of memory allocation before NUMA / hotplug information is fully
> > populated is
On 08/13/2013 12:46 AM, Tejun Heo wrote:
Hello, Tang.
..
But, different users have different ways to use memory hotplug.
Hotswaping any particular chunk of memory is the goal we will reach
finally. But it is on specific hardware. In most current machines, we
can use movable node to
Hey,
On Tue, Aug 13, 2013 at 01:01:09AM +0800, Tang Chen wrote:
> Sorry for the misunderstanding.
>
> I was trying to answer your question: "Why can't the kenrel allocate
> hotpluggable memory opportunistic ?".
I've used the wrong word, I was meaning best-effort, which is the only
thing we can
On 08/12/2013 10:01 AM, Tang Chen wrote:
>>
>>> I'm just thinking of a more extreme case. For example, if a machine
>>> has only one node hotpluggable, and the kernel resides in that node.
>>> Then the system has no hotpluggable node.
>>
>> Yeah, sure, then there's no way that node can be
Hi tj,
On 08/13/2013 12:22 AM, Tejun Heo wrote:
Hello, Tang.
On Tue, Aug 13, 2013 at 12:19:02AM +0800, Tang Chen wrote:
The kernel can export info to users. The point is what kind of info.
Exporting phys addr is meaningless, of course. Now in /sys, we only
have memory_block and node.
Hello, Tang.
On Tue, Aug 13, 2013 at 12:29:51AM +0800, Tang Chen wrote:
> As you said, we can ensure at least one node to be unhotplug. Then the
> kernel will boot anyway. Just like CPU0. But we have the chance to lose
> one movable node.
>
> The best way is firmware and software corporate
On 08/12/2013 11:23 PM, Tejun Heo wrote:
Hello,
On Mon, Aug 12, 2013 at 08:14:04AM -0700, H. Peter Anvin wrote:
It gets really messy if it is advisory. Suddenly you have the user
thinking they can hotswap a memory bank and they just can't.
I'm very skeptical that not doing the strict
Hello, Tang.
On Tue, Aug 13, 2013 at 12:19:02AM +0800, Tang Chen wrote:
> The kernel can export info to users. The point is what kind of info.
> Exporting phys addr is meaningless, of course. Now in /sys, we only
> have memory_block and node. memory_block is only 128M on x86, and
> hotplug a
On 08/12/2013 11:46 PM, Tejun Heo wrote:
Hello,
On Mon, Aug 12, 2013 at 11:41:25PM +0800, Tang Chen wrote:
Then there is no way to tell the users which memory is hotpluggable.
phys addr is not user friendly. For users, node or memory device is the
best. The firmware should arrange the
Hello,
On Mon, Aug 12, 2013 at 11:41:25PM +0800, Tang Chen wrote:
> Then there is no way to tell the users which memory is hotpluggable.
>
> phys addr is not user friendly. For users, node or memory device is the
> best. The firmware should arrange the hotpluggable ranges well.
I don't follow.
On 08/12/2013 10:50 PM, Tejun Heo wrote:
Hello,
..
I think it's in a much better shape than before but there still are a
couple things bothering me.
* Why can't it be opportunistic? It's silly, for example, to fail
boot because ACPI tells the kernel that all memory is hotpluggable
Hello,
On Mon, Aug 12, 2013 at 08:14:04AM -0700, H. Peter Anvin wrote:
> It gets really messy if it is advisory. Suddenly you have the user
> thinking they can hotswap a memory bank and they just can't.
I'm very skeptical that not doing the strict re-ordering would
increase the chance of
On 08/12/2013 07:50 AM, Tejun Heo wrote:
>
> * Why can't it be opportunistic? It's silly, for example, to fail
> boot because ACPI tells the kernel that all memory is hotpluggable
> especially as there'd be plenty of memory sitting around doing
> nothing and failing to boot is one of the
Hello,
On Thu, Aug 08, 2013 at 06:16:12PM +0800, Tang Chen wrote:
> [How we do this]
>
> In ACPI, SRAT(System Resource Affinity Table) contains NUMA info. The memory
> affinities in SRAT record every memory range in the system, and also, flags
> specifying if the memory range is hotpluggable.
>
On 08/10/2013 12:32 AM, Tejun Heo wrote:
Hello,
On Thu, Aug 08, 2013 at 06:16:12PM +0800, Tang Chen wrote:
In previous parts' patches, we have obtained SRAT earlier enough, right after
memblock is ready. So this patch-set does the following things:
Can you please set up a git branch with all
On 08/10/2013 12:32 AM, Tejun Heo wrote:
Hello,
On Thu, Aug 08, 2013 at 06:16:12PM +0800, Tang Chen wrote:
In previous parts' patches, we have obtained SRAT earlier enough, right after
memblock is ready. So this patch-set does the following things:
Can you please set up a git branch with all
Hello,
On Thu, Aug 08, 2013 at 06:16:12PM +0800, Tang Chen wrote:
[How we do this]
In ACPI, SRAT(System Resource Affinity Table) contains NUMA info. The memory
affinities in SRAT record every memory range in the system, and also, flags
specifying if the memory range is hotpluggable.
On 08/12/2013 07:50 AM, Tejun Heo wrote:
* Why can't it be opportunistic? It's silly, for example, to fail
boot because ACPI tells the kernel that all memory is hotpluggable
especially as there'd be plenty of memory sitting around doing
nothing and failing to boot is one of the most
Hello,
On Mon, Aug 12, 2013 at 08:14:04AM -0700, H. Peter Anvin wrote:
It gets really messy if it is advisory. Suddenly you have the user
thinking they can hotswap a memory bank and they just can't.
I'm very skeptical that not doing the strict re-ordering would
increase the chance of reaching
On 08/12/2013 10:50 PM, Tejun Heo wrote:
Hello,
..
I think it's in a much better shape than before but there still are a
couple things bothering me.
* Why can't it be opportunistic? It's silly, for example, to fail
boot because ACPI tells the kernel that all memory is hotpluggable
Hello,
On Mon, Aug 12, 2013 at 11:41:25PM +0800, Tang Chen wrote:
Then there is no way to tell the users which memory is hotpluggable.
phys addr is not user friendly. For users, node or memory device is the
best. The firmware should arrange the hotpluggable ranges well.
I don't follow. Why
On 08/12/2013 11:46 PM, Tejun Heo wrote:
Hello,
On Mon, Aug 12, 2013 at 11:41:25PM +0800, Tang Chen wrote:
Then there is no way to tell the users which memory is hotpluggable.
phys addr is not user friendly. For users, node or memory device is the
best. The firmware should arrange the
Hello, Tang.
On Tue, Aug 13, 2013 at 12:19:02AM +0800, Tang Chen wrote:
The kernel can export info to users. The point is what kind of info.
Exporting phys addr is meaningless, of course. Now in /sys, we only
have memory_block and node. memory_block is only 128M on x86, and
hotplug a
On 08/12/2013 11:23 PM, Tejun Heo wrote:
Hello,
On Mon, Aug 12, 2013 at 08:14:04AM -0700, H. Peter Anvin wrote:
It gets really messy if it is advisory. Suddenly you have the user
thinking they can hotswap a memory bank and they just can't.
I'm very skeptical that not doing the strict
Hello, Tang.
On Tue, Aug 13, 2013 at 12:29:51AM +0800, Tang Chen wrote:
As you said, we can ensure at least one node to be unhotplug. Then the
kernel will boot anyway. Just like CPU0. But we have the chance to lose
one movable node.
The best way is firmware and software corporate together.
Hi tj,
On 08/13/2013 12:22 AM, Tejun Heo wrote:
Hello, Tang.
On Tue, Aug 13, 2013 at 12:19:02AM +0800, Tang Chen wrote:
The kernel can export info to users. The point is what kind of info.
Exporting phys addr is meaningless, of course. Now in /sys, we only
have memory_block and node.
On 08/12/2013 10:01 AM, Tang Chen wrote:
I'm just thinking of a more extreme case. For example, if a machine
has only one node hotpluggable, and the kernel resides in that node.
Then the system has no hotpluggable node.
Yeah, sure, then there's no way that node can be hotpluggable and the
Hey,
On Tue, Aug 13, 2013 at 01:01:09AM +0800, Tang Chen wrote:
Sorry for the misunderstanding.
I was trying to answer your question: Why can't the kenrel allocate
hotpluggable memory opportunistic ?.
I've used the wrong word, I was meaning best-effort, which is the only
thing we can do
On 08/13/2013 12:46 AM, Tejun Heo wrote:
Hello, Tang.
..
But, different users have different ways to use memory hotplug.
Hotswaping any particular chunk of memory is the goal we will reach
finally. But it is on specific hardware. In most current machines, we
can use movable node to
Hello,
On Tue, Aug 13, 2013 at 02:23:13AM +0800, Tang Chen wrote:
* However, we already *know* that the memory the kernel image is
occupying won't be removeable. It's highly likely that the amount
of memory allocation before NUMA / hotplug information is fully
populated is pretty
Hello,
On Thu, Aug 08, 2013 at 06:16:12PM +0800, Tang Chen wrote:
> In previous parts' patches, we have obtained SRAT earlier enough, right after
> memblock is ready. So this patch-set does the following things:
Can you please set up a git branch with all patches?
Thanks.
--
tejun
--
To
Hello,
On Thu, Aug 08, 2013 at 06:16:12PM +0800, Tang Chen wrote:
In previous parts' patches, we have obtained SRAT earlier enough, right after
memblock is ready. So this patch-set does the following things:
Can you please set up a git branch with all patches?
Thanks.
--
tejun
--
To
[Problem]
The current Linux cannot migrate pages used by the kerenl because
of the kernel direct mapping. In Linux kernel space, va = pa + PAGE_OFFSET.
When the pa is changed, we cannot simply update the pagetable and
keep the va unmodified. So the kernel pages are not migratable.
There are also
[Problem]
The current Linux cannot migrate pages used by the kerenl because
of the kernel direct mapping. In Linux kernel space, va = pa + PAGE_OFFSET.
When the pa is changed, we cannot simply update the pagetable and
keep the va unmodified. So the kernel pages are not migratable.
There are also
74 matches
Mail list logo
