Create an Expanded Ashmem Unit Test

Registered by Zach Pfeffer on 2012-12-18

Why?
Ashmem is a key component in Android and any changes to it should be unit-tested.

Context?
Android kernel upstreaming and development.

What gets produced?
An expanded unit-test that tests ashmem.

Where will the work get put?
In a private git.

Blueprint information

Status:
Complete
Approver:
Zach Pfeffer
Priority:
Essential
Drafter:
Dmitry Antipov
Direction:
Approved
Assignee:
Dmitry Antipov
Definition:
Approved
Series goal:
Accepted for juice
Implementation:
Implemented
Milestone target:
milestone icon m2
Started by
Jakub Pavelek on 2013-01-18
Completed by
Jakub Pavelek on 2013-02-27

Related branches

Sprints

Whiteboard

Notes:
[2012/12/18 pfefferz] Please put notes here.
[2012/12/18 pfefferz] This expanded test task is based on an expanded test suggested by John Stultz:

So doing various combinations of page range unpinning and re-pinning (not necessarily one-to-one) is useful in shaking out bugs.
Developing complicated unpin/pin patterns suggest that the test should take an input file with a list of operations.
ie:
  #checker board, alternating unpinned/pinned regions ie: (0-10)(20-30)(40-50) unpinned
  unpin 0 10
  unpin 20 10
  unpin 40 10
  generate_pressure 500M
 # re-pin both unpinned and pinned pages from 0-20
  pin 0 20
 # repin everything
  pin 0 50

Having it print out the return values (including purge state). This allows errors in the underlying management of the ranges to be found. Also it allows finer grained testing of the purging logic (which can help show behavioral changes, like the purging order, when we don't purge everything, etc).

Also the generate_pressure bit is a useful test as well. Basically you just need to call fork() - important, as you risk OOM'ing the test otherwise -, and then have the child allocate and traverse chunks of memory, up to some specified amount. That should generate enough pressure to trigger VM reclamation with the shirnker. And If the amount is large enough, it will trip the OOM killer, and kill off the child. Either way, the test application should observe purged ranges after that.

[2013/01/21 antipov] There is simpler and more reliable way to enforce the kernel to run cache shrinker - echo 3 > /proc/sys/vm/drop_caches.

[2012/12/19 pundiramit] LAVA integration is handled via https://blueprints.launchpad.net/linaro-android/+spec/lava-integrate-ashmem-unit-test.

[2013/01/16 antipov] Initial version of the test is at http://git.linaro.org/gitweb?p=people/antipov/ashmemtest-expanded.git;a=summary

[2013/1/30] Added a note to request completion by the end of 13.02

[2013/02/19 antipov] Verified that the test works with https://android-build.linaro.org/builds/~linaro-android-restricted/juice-aosp/#build=121 (with commit https://linaro-private.git.linaro.org/gitweb?p=android/linaro-android-kernel-test.git;a=commit;h=49923809689076225ab0c1c9df74f031b9d4310e).
[jakub-pavelek 2013-02-27] Marking as Implemented based on last comment and WI status

Meta:
Duration: 2w
Headline: We now have an expanded ashmem unit test
Roadmap id: CARD-335
Acceptance:
1. An expanded userspace binder unit-test that tests all aspects of ashmem

(?)

Work Items

Work items for 13.01:
Develop simple scenario that enforces the kernel to run ashmem cache shrinker: DONE
Modify the test plan available from Zach Pfeffer to include how to run the expanded test: DONE
Create the expanded test (code is considered finished per dmitry's comment in email - Jan 29): DONE

Work items for 13.02:
[fagerstedt-axel] Integrate unit test into private git repo: DONE
Add checkerboard unpin (unpin 1 meg every other meg for 50 megs), single repin all test: DONE
Add checkerboard unpin (unpin 1 meg every other meg for 50 megs), cumulative repin (repin 0-1 meg, 0-2 meg, 0-3meg....0-50meg) test: DONE
Finish development and build integration by 2013/2/21: DONE
Haven't heard anything on this for awhile, so I believe its all done: DONE

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.