Re: [PATCH part5 0/7] Arrange hotpluggable memory as ZONE_MOVABLE.

From: KOSAKI Motohiro
Date: Wed Aug 14 2013 - 16:28:53 EST


(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 default the feature.

Yeah, some options are "please try this" and others "do this or fail".
There's no frigging fundamental rule there.

In this case, we have zero worth for fallback, right?


I don't read whole discussion and I don't quite understand why no kernel
place controlling is relevant. Every unpluggable node is suitable for
kernel. If you mean current kernel placement logic don't care plugging,
that's a bug.

If we aim to hot remove, we have to have either kernel relocation or
hotplug awre kernel placement at boot time.

What if all nodes are hot pluggable? Are we moving the kernel
dynamically then?

Intel folks already told, we have no such system in practice.


Failing to boot is *way* worse reporting mechanism than almost
everything else. If the sysadmin is willing to risk machines failing
to come up, she would definitely be willing to check whether which
memory areas are actually hotpluggable too, right?

No. see above. Your opinion is not pragmatic useful.

No, what you're saying doesn't make any sense. There are multiple
ways to report when something doesn't work. Failing to boot is *one*
of them and not a very good one. Here, for practical reasons, the end
result may differ depending on the specifics of the configuration, so
more detailed reporting is necessary anyway, so why do you insist on
failing the boot? In what world is it a good thing for the machine to
fail boot after bios or kernel update?

Because boot failure have no chance to overlook and better way for practice.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/