Re: [Discuss] First steps for ASI (ASI is fast again)

[Uladzislau Rezki <urezki@gmail.com>]

On Fri, Aug 22, 2025 at 05:20:28PM +0000, Brendan Jackman wrote:
> On Fri Aug 22, 2025 at 4:56 PM UTC, Uladzislau Rezki wrote:
> >> >> 2. The ephmap implementation is extremely stupid. It only works for the simple
> >> >>    shmem usecase. I don't think this is really important though, whatever we end
> >> >>    up with needs to be very simple, and it's not even clear that we actually
> >> >>    want a whole new subsystem anyway. (e.g. maybe it's better to just adapt
> >> >>    kmap_local_page() itself).
> >> >
> >> > Right just testing stuff out, fair enough. Obviously not an upstremable thing
> >> > but sort of test case right?
> >> 
> >> Yeah exactly. 
> >> 
> >> Maybe worth adding here that I explored just using vmalloc's allocator
> >> for this. My experience was that despite looking quite nicely optimised
> >> re avoiding synchronisation, just the simple fact of traversing its data
> >> structures is too slow for this usecase (at least, it did poorly on my
> >> super-sensitive FIO benchmark setup).
> >> 
> > Could you please elaborate here? Which test case and what is a problem
> > for it?
> 
> What I'm trying to do here is allocate some virtual space, map some
> memory into it, read it through that mapping, then tear it down again.
> The test case was an FIO benchmark reading 4k blocks from tmpfs, which I
> think is a pretty tight loop. Maybe this is the kinda thing where the
> syscall overhead is pretty significant, so that it's an unrealistic
> workload, I'm not too sure. But it was a nice way to get a maximal
> measure of the ASI perf hit on filesystem access.
> 
> I didn't make careful notes but I vaguely remember I was seeing
> something like 10% hits to this workload that I attributed to the
> vmalloc calls based on profiling with perf.
> 
If you could post a perf profiling data for your workload that would
be more helpful. At least i could figure where the cycles are consumed
the most in vmalloc path.

Thanks!

--
Uladzislau Rezki