Re: [LTP] [PATCH v4] shell: enable OOM protection by default

[Andrea Cervesato via ltp <ltp@lists.linux.it>]

Hi Li,

> Hi Andrea, Petr,
> 
> After looking into it more, now I slightly think doing OOM protection
> in the shell harness isn't worth it: the benefit doesn't justify the
> complexity. Forking the whole test body means dealing with cleanup and
> timer ownership across the fork, plus passing results back from the
> child, and all of that would need revalidating for every shell test
> that goes through tst_test.sh.
> 
> Given that only a few tests actually produce memory pressure, I'd
> rather keep it simple and handle it locally in those tests instead of
> touching the common harness. Something like a small helper the test
> can wrap the memory hungry workload with:
> 
>     tst_oom_run()
>     {
>         ( echo 0 > /proc/self/oom_score_adj; exec "$@" )
>     }
> 
> The harness (or the setup) protects itself with oom_score_adj -1000,
> and only the workload started via tst_oom_run stays killable.
> This keeps the harness alive to report results without forking the
> whole test body, and matches the C harness model where the worker is
> the unprotected part.
> 
> Does this direction make sense to you, or do you see a case that
> really needs the protection to be harness-wide?

I think you are right, perhaps these shell tests need to be rewritten in
C anyway. Most of them are unstable and fificult to maintain (like all
shell scripts anyway).

I can go back to my original idea of setting oom protection only
for specific tests.

>  
> > Suggested-by: Li Wang <liwang@redhat.com>
> 
> This email address is no longer in use :).

Ah damn.. :-D

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp