On Tue, Nov 29, 2016 at 9:28 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote:
> How does this warning help those who are watching the logs? What are
> they supposed to do about it? Unlike GFP_ATOMIC there is no tuning you
> can possibly do.
You can report it and it will get fixed.
It's not about tuning. It's about people like Tejun who made changes
and didn't do them right.
In other words, exactly the patch that this whole thread started with.
Except that because of the idiotic arguments about the *obvious*
patch, the patch gets delayed and not applied.
The whole __GFP_NOWARN thing is not some kind of newfangled thing that
suddenly became a problem. It's been there for decades. Why are you
arguing for stupidly removing it now?
> I am confused, how can anybody _rely_ on GFP_NOWAIT to succeed?
You can't (except perhaps during bootup).
BUT YOU HAVE TO HAVE A FALLBACK, AND SHOW THAT YOU ARE *AWARE* THAT
YOU CAN"T RELY ON IT.
Christ. What's so hard to understand about this?
And no, GFP_NOWAIT is not special. Higher orders have the exact same
issue. And they too need that __GFP_NOWARN to show that "yes, I know,
and yes, I have a fallback strategy".
Because that warning shows real bugs. Seriously. We had fix for this
pending for 4.10 already (nfsd just blithely assuming it can do big
allocations).
So stop the idiotic arguments. The whole point is that lots of people
don't think about allocations failing (and NOWAIT and friends do not
change that ONE WHIT), and __GFP_NOWARN is there exactly to show that
you thought about them.
The warning _has_ been useful. We're not hiding it by default, because
that makes the whole warning pointless.
Really.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>