From: Bill Fischofer [mailto:[email protected]] Sent: Wednesday, June 29, 2016 4:43 AM To: Savolainen, Petri (Nokia - FI/Espoo) <[email protected]> Cc: [email protected] Subject: Re: [lng-odp] [PATCH 2/2] validation: queue: use malloc to avoid artificial limits on max_queues
I've sent a v2 to address these concerns On Tue, Jun 28, 2016 at 2:15 AM, Savolainen, Petri (Nokia - FI/Espoo) <[email protected]> wrote: Purpose of the test is to first of all check that .max_queues field is defined and filled. Malloc may not be usable always for storing maximum number of resource handles. May be the platform under test provides 16 GB shm memory, but only 1GB general system memory backed up by a hard disk. A malloc of 800MB could stuck the system totally (generally fast path applications avoid using malloc), but a 800MB shm allocation would work just fine. I think it would be better idea to add another test case which really tries to create and use the max number of queues, groups, priorities, etc. So that it's easier contain failure cases between the capability call not supported vs. failure to use maximum (very large) number of resource X. v2 falls back to a 64K test if the malloc() fails. <<< Reply to a HTML mail ... >>> The issue with huge mallocs is that the malloc succeeds and operating system starts swapping memory to hard disk and back, which stucks the application. It may take minutes to run through a single test, or OS (Linux) may decide to kill the thread after some minutes, etc. That's why huge mallocs should be avoided in this suite, as it should be able run on a variety of (embedded) systems. In minimum, huge mallocs should be contained into separate test cases, so that it's easy to skip a test that gets stuck. I'd add this as another test case (e.g. queue_test_max_num_queues) and separate from queue_test_capa, which currently checks that the capa API is there. Also the new max_num_queues test should try to enqueue some events through every queue. -Petri _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
