Re: [RFC PATCH] vm: align vma allocation and move the lock back into the struct

[Mateusz Guzik <mjguzik@gmail.com>]

On Mon, Aug 12, 2024 at 12:50 AM Suren Baghdasaryan <surenb@google.com> wrote:
> Ok, disabling adjacent cacheline prefetching seems to do the trick (or
> at least cuts down the regression drastically):
>
> Hmean     faults/cpu-1    470577.6434 (   0.00%)   470745.2649 *   0.04%*
> Hmean     faults/cpu-4    445862.9701 (   0.00%)   445572.2252 *  -0.07%*
> Hmean     faults/cpu-7    422516.4002 (   0.00%)   422677.5591 *   0.04%*
> Hmean     faults/cpu-12   344483.7047 (   0.00%)   330476.7911 *  -4.07%*
> Hmean     faults/cpu-21   192836.0188 (   0.00%)   195266.8071 *   1.26%*
> Hmean     faults/cpu-30   140745.9472 (   0.00%)   140655.0459 *  -0.06%*
> Hmean     faults/cpu-48   110507.4310 (   0.00%)   103802.1839 *  -6.07%*
> Hmean     faults/cpu-56    93507.7919 (   0.00%)    95105.1875 *   1.71%*
> Hmean     faults/sec-1    470232.3887 (   0.00%)   470404.6525 *   0.04%*
> Hmean     faults/sec-4   1757368.9266 (   0.00%)  1752852.8697 *  -0.26%*
> Hmean     faults/sec-7   2909554.8150 (   0.00%)  2915885.8739 *   0.22%*
> Hmean     faults/sec-12  4033840.8719 (   0.00%)  3845165.3277 *  -4.68%*
> Hmean     faults/sec-21  3845857.7079 (   0.00%)  3890316.8799 *   1.16%*
> Hmean     faults/sec-30  3838607.4530 (   0.00%)  3838861.8142 *   0.01%*
> Hmean     faults/sec-48  4882118.9701 (   0.00%)  4608985.0530 *  -5.59%*
> Hmean     faults/sec-56  4933535.7567 (   0.00%)  5004208.3329 *   1.43%*
>
> Now, how do we disable prefetching extra cachelines for vm_area_structs only?

I'm unaware of any mechanism of the sort.

The good news is that Broadwell is an old yeller and if memory serves
right the impact is not anywhere near this bad on newer
microarchitectures, making "merely" 64 alignment (used all over in the
kernel for amd64) a practical choice (not just for vma).

Also note that in your setup you are losing out on performance in
other multithreaded cases, unrelated to anything vma.

That aside as I mentioned earlier the dedicated vma lock cache results
in false sharing between separate vmas, except this particular
benchmark does not test for it (which in your setup should be visible
even if the cache grows the  SLAB_HWCACHE_ALIGN flag).

I think the thing to do here is to bench on other cpus and ignore the
Broadwell + adjacent cache line prefetcher result if they come back
fine -- the code should not be held hostage by an old yeller.

To that end I think it would be best to ask the LKP folks at Intel.
They are very approachable so there should be no problem arranging it
provided they have some spare capacity. I believe grabbing the From
person and the cc list from this thread will do it:
https://lore.kernel.org/oe-lkp/ZriCbCPF6I0JnbKi@xsang-OptiPlex-9020/ .
By default they would run their own suite, which presumably has some
overlap with this particular benchmark in terms of generated workload
(but I don't think they run *this* particular benchmark itself,
perhaps it would make sense to ask them to add it?). It's your call
here.

If there are still problems and the lock needs to remain separate, the
bare minimum damage-controlling measure would be to hwalign the vma
lock cache -- it wont affect the pts benchmark, but it should help
others.

Should the decision be to bring the lock back into the struct, I'll
note my patch is merely slapped together to a state where it can be
benchmarked and I have no interest in beating it into a committable
shape. You stated you already had an equivalent (modulo keeping
something in a space previously occupied by the pointer to the vma
lock), so as far as I'm concerned you can submit that with your
authorship.
-- 
Mateusz Guzik <mjguzik gmail.com>