Add some basic test coverage for SHM_LARGEPAGE.
ClosedPublic
Actions

Authored by markj on Jul 31 2020, 1:51 AM.

Details

Reviewers

kib

Commits

rS365840: Add some basic regression tests for SHM_LARGEPAGE.

Summary

Some areas are not handled yet, in particular minherit() and
interactions with COW.

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 33340
Build 30651: arc lint + arc unit

markj requested review of this revision.Jul 31 2020, 1:51 AM

markj created this revision.

This is not complete, I posted it in case you find it useful.

tests/sys/posixshm/posixshm_test.c
972	In fact we need a reasonable userspace API which would wrap shm_open2() and FIOSHMLPGCNF. That was one of the reasons why I did not exported shm_open2().
990	JFYI, MAXPAGESIZES is too static. Kernel can provide more page sizes than MAXPAGESIZES, e.g. i386 running on amd64 kernel. More, in principle 32bit process can get 2 or even 3 1G superpage mappings

tests/sys/posixshm/posixshm_test.c
972	Do you think it is reasonable to provide parameters as a structure, i.e., struct shm_largepage_conf? Or should they be passed as individual parameters?

tests/sys/posixshm/posixshm_test.c
972	I think passing parameters as function arguments is fine. It is somewhat less flexible from the ABI PoV, since we can add padding to the structure to allow extension. Another question, do we think that it is fine to expose psidx and require user to fetch pagesizes[] to use the API ? Or should we go with Linux memfd() approach, see my patch for libc. The existing SHM_LARGEPAGE/FIOSHMLPGCNF approach is fine for kernel interface, but for user we might provide something nicer.

tests/sys/posixshm/posixshm_test.c
972	Sorry, I missed your question. I think it is probably reasonable to continue using psind, since it also provides information about the supported page sizes which applications probably want to see anyway.