On 8/18/20 6:17 AM, Chris Down wrote:
peterz@xxxxxxxxxxxxx writes:
But then how can it run-away like Waiman suggested?
Probably because he's not running with that commit at all. We and
others use this to prevent runaway allocation on a huge range of
production and desktop use cases and it works just fine.
/me goes look... and finds MEMCG_MAX_HIGH_DELAY_JIFFIES.
That's a fail... :-(
I'd ask that you understand a bit more about the tradeoffs and
intentions of the patch before rushing in to declare its failure,
considering it works just fine :-)
Clamping the maximal time allows the application to take some action
to remediate the situation, while still being slowed down
significantly. 2 seconds per allocation batch is still absolutely
plenty for any use case I've come across. If you have evidence it
isn't, then present that instead of vague notions of "wrongness".
Sorry for the late reply.
I ran some test on the latest kernel and and it seems to work as
expected. I was running the test on an older kernel that doesn't have
this patch and I was not aware of it before hand.
Sorry for the confusion.
Cheers,
Longman
