[LTP] [RFC PATCH 1/3] lib: extend .request_hugepages to guarantee enough pages

[Li Wang]

Cyril Hrubis <chrubis@suse.cz> wrote:


> +TST_FLEXIBLE:
> > +  If set non-zero number in .request_hugepages, ltp will try to reserve
> the
> > +  expected number of hugepage for testing in setup phase. If system
> does not
> > +  have enough memory for that, it will try the best to reserve 80%
> available
> > +  huge pages.
> > +
> > +TST_ENFORCED:
> > +  This is an enforced requirement for huge page reserve, ltp should
> strictly do
> > +  hpages applying and guarantee the 'HugePages_Free' no less than
> specified pages
> > +  which gives that test can use these specified numbers correctly.
>
> As for the naming I would probably go for TST_NEEDS and TST_REQUEST. We
> use the word 'needs' in the tst_test to describe something that is
> required for the test. And 'request' sounds better to me than flexible
> in a sense that you can request a lot but get less than what was
> requested.
>

Sounds better, if so, I'd also rename '.request_hugepages' to '.hugepages'
in tst_test because there have been overlaps in the tst_policy words.

 struct tst_test test = {
        .test_all = run,
-       .request_hugepages = 2,
+       .hugepages = {2, TST_REQUEST},
        ...
 };
No hugepage change to:

    .hugepages = {TST_NO_HUGEPAGES, TST_REQUEST},

API in header file change to:

-unsigned long tst_request_hugepages(unsigned long hpages);
+unsigned long tst_reserve_hugepages(struct tst_hugepage *hp);

> -     unsigned long request_hugepages;
> > +     struct tst_hugepage *request_hugepages;
>
> Why is this treated as an array even though we work with only single
> struct tst_hugepage instance?
>

Right, it no needs an array in that case.


-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20220602/f6c60de8/attachment.htm>