Re: [ANNOUNCE] jio is an experimental systemd-journald journal file tool utilizing io_uring

[Vito Caputo <vcaputo@xxxxxxxxxxx>]

On Thu, Nov 26, 2020 at 07:58:38PM +0100, Lennart Poettering wrote:
> On Mi, 25.11.20 19:02, Vito Caputo (vcaputo@xxxxxxxxxxx) wrote:
> 
> > Hello systemd-devel,
> >
> > Recent discussion here about journal space consumption happened to
> > occur while I was exploring use of the new io_uring linux kernel
> > interface in combination with journal files.
> 
> I'd be really curious if a iouring based reader could outperform the
> mmap based ones. I have the suspicion that yes, since paging in stuff
> is slow, and doesn't really allow for reordering.
> 

Same here, I expect superior uncached performance, and either equal or
slightly worse cached performance.

So the worst case should be better, and it might be a worthwhile trade
off for that alone.  Also the programming style is inherently quite
different, not sure if it's a net win or loss there, probably depends
on the preference of who's stuck maintaining it.

I'm also curious to see if io_uring is efficient enough that one can
treat the page cache as the application cache, and completely skip
implementing (and allocating space for) any caching layer in the
userspace process.

In jio currently, all the tiny object header reads of `jio report
usage` are being done with discrete io_uring requests, there's no
equivalent to the mmap-cache found in systemd-journald.

This results in frequently crossing the application:kernel boundary,
granularly fetching journal data from the page cache.  It makes for a
*very* simple implementation, and the kind of thing you'd strongly try
to avoid when using something like plain read() syscalls if concerned
with performance.

My knee-jerk reaction to such an approach is it'd be crazy to not even
cache the entry arrays and some hot set of entries and data objects
local to the process during searches at least.  But starting with a
dumb implementation leaning hard on io_uring seems worth at least
measuring, and maybe it'd prove Good Enough (tm), while staying within
a much smaller address space.  And it's not like such an
implementation would be difficult to extend with some targeted caching
of objects where needed.

BTW, do you have any objections to jio discussions occuring on
systemd-devel?

Regards,
Vito Caputo
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel