allocation lifecycle

[jnorthrup]

I have primarily only been accessing man pages for recent documentation. reading older material is absent of dozens upon dozens of new features.

first question I have is conceptual inclusive of transactional memory, not excluding GPU IO;one example that comes to mind is whether io_uring is up to the task of Intel's supposed superior Optane userspace approach to driver performance which preceded io_uring. how much of this could be accomplished with io_uring and what are the related issues for extra-kernel buffers?

I'm working in a transitional heap allocation environment in Kotlin for the moment, the language is undergoing rapid changes like native memory models and IR targets each release.

my other Q and most relevant to to my present undertaking, I am just getting my footing in the transcription of the C code without necessarily experiencing all of the use-cases firsthand, are there any asymmetric allocations to be aware of in using liburing api ?

if so what are kernel and libc resources to read up on for object pooling ?

[axboe]

up to the task of Intel's supposed superior Optane userspace approach to driver performance

You'll have to be more specific here, I'm not sure what is being referred to here.

are there any asymmetric allocations to be aware of in using liburing api ?

Only one I can think of is if you use io_uring_get_probe_ring(), which will return allocated memory which should be freed with io_uring_free_probe(). Outside of that, setting up a new ring with io_uring_queue_init() or similar will mmap(2) the ring from the kernel. That's not strictly an allocating, it's just mapping it into the process address space. But it is something that process exit will undo, or io_uring_queue_exit()

[jnorthrup]

up to the task of Intel's supposed superior Optane userspace approach to driver performance

You'll have to be more specific here, I'm not sure what is being referred to here.

It was some years ago when I initially footnoted that the optane drivers were using counter-intuitive userspace-only code to get a huge bump on throughput to/from persistent RAM. Revisiting this post io-uring-invention brings clearer focus - it is direct addressable and gains nothing.

the first relevant search result I came up with just now is https://www.intel.com/content/www/us/en/developer/articles/technical/speeding-up-io-workloads-with-intel-optane-dc-persistent-memory-modules.html and it mentions that optane can just mmap the storage and be done with it, and accessing via async adds undesirable overhead. while Optane also appears to provide a convenient persistent RAM Disk alter-ego, it looks like the focus on Optane drivers is to give attention to ways to keep IO from adding wasteful copy cycles in the CPU cache land.