* Michal Hocko [off-list ref] [170801 04:30]:

On Mon 31-07-17 21:11:25, Liam R. Howlett wrote:

quoted

* Michal Hocko [off-list ref] [170731 10:08]:

quoted

On Mon 31-07-17 09:56:48, Liam R. Howlett wrote:

[...]

quoted

quoted

quoted

No,  I'm talking about failed memory for whatever reason.  The system
reboots by a hardware means (I believe the memory controller) and
removes the memory on that failed module from the pool.  Now you
effectively have a system with less memory than before which invalidates
your configuration.  Is it worth while to have Linux successfully boot
when the system attempts to recover from a failure?

Cetainly yes but if you boot with much less memory and you want to use
hugetlb pages then you have to reconsider and maybe even reconfigure
your workload to reflect new conditions. So I am not really sure this
can be fully automated.

I agree.  A reconfiguration or repair is required to have optimum
performance.  Would you agree that having functioning system better than
a reboot loop or hang on a panic?  It's also easier to reconfigure a
system that's booting.

Absolutely. The thing is that I am not even sure that the hugetlb
problem is real. Using hugetlb reservation from the boot command line
parameter is easily fixable (just update the boot comand line from the
boot loader). From my experience the init time hugetlb initialization
is usually trying to be portable and as such configures a certain
percentage of the available memory for hugetlb (some of them even on per
NUMA node basis). Even if somebody uses hard coded values then this is
something that is fixable during recovery.

This was my thought when I was first assigned the bug for my last patch
for adding the log message of the hugetlb allocation failure but during
our discussion I was assigned two more near-identical bugs.  From what I
can tell the people following a setup guide do not know how to edit the
grub command line easily once in a boot loop or don't have a decent
enough console setup to do so.  Worse yet, all three of the bugs were
filed as kernel bugs because people didn't even realise it was a setup
issue.  I think the sysctl way of setting the hugetlb is the safest.
But since we provide a kernel command line way of setting the hugetlb,
it seems reasonable to make the user error as transparent as possible.
This RFC was an extension of looking at how people arrive at an OOM
error on boot when using hugetlb.

That being said I am not sure you are focusing on a real problem while
the solution you are proposing might break an existing userspace. Please
try to play with your memory recovery feature some more with real
hugetlb usecases (Oracle DB is a heavy user AFAIR) and see what the real
life problems might happen and we can revisit potential solutions with
more data in hands.

Okay, thank you.  I will re-examine the issue and see about a different
approach.  I appreciate the time you have taken to look at my RFC.

Thanks,
Liam

--
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>