Page MenuHomeFreeBSD

Add some basic test coverage for SHM_LARGEPAGE.
Needs ReviewPublic

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

Details

Reviewers
kib
Summary

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

Diff Detail

Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 32671
Build 30123: arc lint + arc unit

Event Timeline

markj requested review of this revision.Fri, Jul 31, 1:51 AM
markj created this revision.
markj added a reviewer: kib.Fri, Jul 31, 1:52 AM

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

kib added inline comments.Fri, Jul 31, 5:27 PM
tests/sys/posixshm/posixshm_test.c
971

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

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

markj added inline comments.Fri, Jul 31, 5:34 PM
tests/sys/posixshm/posixshm_test.c
971

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?

kib added inline comments.Fri, Jul 31, 6:45 PM
tests/sys/posixshm/posixshm_test.c
971

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.