Marcin Ślusarz

If I understand correctly, your performance improvement comes from parallelizing transaction commit and this means that cross-pool transactions wouldn't help you. Parallelizing transaction commit is a feature on its own...

pmempool doesn't create poolset files by design. Autogrowing poolsets are no different than other types of poolsets, so I don't see why we should implement this particular feature, but leave...

Possible solutions: - fixing the underlying issue :) - multi-threaded detaching - daemon mode (one background process waiting on Unix socket and another one controlling it)

Another idea is to use per syscall tracepoints - detaching from them should be faster than from kprobes.

This is blocked on missing support in pmemobj for aligned allocations.

Aligned allocations are available since pmem/pmdk#2654 (pmemobj >= 1.5)

Reviewed 13 of 18 files at r1. Review status: 13 of 18 files reviewed at latest revision, 10 unresolved discussions. --- *[src/libpmemfile-posix/pool.c, line 357 at r1](https://reviewable.io:443/reviews/pmem/pmemfile/419#-Kw5JUX9W1blEQ1VtDuj:-Kw5JUXAn8DSCKypGxzF:bypawht) ([raw file](https://github.com/pmem/pmemfile/blob/dfc870532adbf7da27abb995d52bc53bacfc61f2/src/libpmemfile-posix/pool.c#L357)):* > ```C...

One possible solution to this problem is substituting libc functions we use in pmemfile and pmemobj by simpler variant that do not call file related syscalls when called FROM pmemfile...

For testing purposes we now have very slow emulation of multi-process support, enabled by PMEMFILE_PRELOAD_PROCESS_SWITCHING environment variable. (#279)

Another workaround is pmemfile-fuse, which we have since #358. It's relatively slow, but much faster than process switching.