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.

Repository

rS FreeBSD src repository - subversion

Lint

Lint Not Applicable

Unit

Tests Not Applicable

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
971 ↗	(On Diff #75195)	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().
989 ↗	(On Diff #75195)	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
971 ↗	(On Diff #75195)	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
971 ↗	(On Diff #75195)	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
971 ↗	(On Diff #75195)	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.