Re: [RFC PATCH] mm: memcontrol: reign in CONFIG space madness

[Johannes Weiner]

On Thu, Dec 10, 2015 at 05:12:12PM +0100, Michal Hocko wrote:
> This is what we call a review process. Raise concerns and deal with
> them. My review hasn't implied this would be a show stopper or block
> those change to get merged. I was merely asking whether we can keep
> the code size with a _reasonable_ maintenance burden. If the answer is
> no then I can live with that even when I might not like that fact. That
> has been reflected by a lack of my acked-by.

Everything we do bears a cost, our entire work is making tradeoffs
(with a few exceptions where code is just dumb). So when you bring up
cost, you have to weigh it against what you're trading off. There is
simply no value in saying "this costs X" and nothing else. It's
meaningless on its own. Unless X is so unreasonably large that there
MUST be another way of doing it, and investing the time is worth it.

8K is not unreasonably large given the history and overall trend of
the memcg code. And the only possible tradeoff is to make even more
CONFIG options and encourage balkanization of cgroup users, which is
hardly a reasonable route to go down. So what exactly ARE you saying
when you post `size' results that you don't consider show stoppers?
That you don't like increasing the kernel size? Do you think I do?

Pointing out the unexpected (bugs, excessive cost, design problems) is
part of a healthy review process. Proposing a different tradeoff,
supported by a cost/benefit analysis in both directions is useful.

What's happening here is definitely not a constructive review process.

> You sound as if you had to overrule a nack which sounds like over
> reacting because this is not the case.

Issues raised are usually considered showstoppers unless it's clear
from the way they're raised that we can live with them.

And I'm tired of having the same discussion over and over.
--
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/