<span style=" font-size:10pt;font-family:sans-serif">I don't know anything
about VAS page size requirements in the kernel. I checked the user
compression library and saw that we do a sysconf to get the page size;
so the library should be immune to page size by design.</span><br><span style=" font-size:10pt;font-family:sans-serif">But it wouldn't
surprise me if a 64KB constant is inadvertently hardcoded somewhere else
in the library. Giving heads up to Tulio and Raphael who are owners
of the github repo.</span><br><br><a href="https://github.com/libnxz/power-gzip/blob/master/lib/nx_zlib.c#L922"><span style=" font-size:10pt;color:blue;font-family:sans-serif">https://github.com/libnxz/power-gzip/blob/master/lib/nx_zlib.c#L922</span></a><br><br><span style=" font-size:10pt;font-family:sans-serif">If we got this
wrong in the library it might manifest itself as an error message of the
sort "excessive page faults". The library must touch pages
ahead to make them present in the memory; occasional page faults is acceptable.
It will retry.</span><br><br><br><span style=" font-size:10pt;font-family:sans-serif">Bulent</span><br><br><br><br><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"Sukadev
Bhattiprolu" <sukadev@linux.ibm.com></span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"Christophe
Leroy" <christophe.leroy@csgroup.eu></span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Cc:
</span><span style=" font-size:9pt;font-family:sans-serif">"Will
Springer" <skirmisher@protonmail.com>, linuxppc-dev@lists.ozlabs.org,
daniel@octaforge.org, Bulent Abali/Watson/IBM@IBM, haren@linux.ibm.com</span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">12/01/2020
12:53 AM</span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">Re:
CONFIG_PPC_VAS depends on 64k pages...?</span><br><hr noshade><br><br><br><tt><span style=" font-size:10pt"><br>Christophe Leroy [christophe.leroy@csgroup.eu] wrote:<br>> Hi,<br>> <br>> Le 19/11/2020 à 11:58, Will Springer a écrit :<br>> > I learned about the POWER9 gzip accelerator a few months ago
when the<br>> > support hit upstream Linux 5.8. However, for some reason the
Kconfig<br>> > dictates that VAS depends on a 64k page size, which is problematic
as I<br>> > run Void Linux, which uses a 4k-page kernel.<br>> > <br>> > Some early poking by others indicated there wasn't an obvious
page size<br>> > dependency in the code, and suggested I try modifying the config
to switch<br>> > it on. I did so, but was stopped by a minor complaint of an "unexpected
DT<br>> > configuration" by the VAS code. I wasn't equipped to figure
out exactly what<br>> > this meant, even after finding the offending condition, so after
writing a<br>> > very drawn-out forum post asking for help, I dropped the subject.<br>> > <br>> > Fast forward to today, when I was reminded of the whole thing
again, and<br>> > decided to debug a bit further. Apparently the VAS platform device<br>> > (derived from the DT node) has 5 resources on my 4k kernel, instead
of 4<br>> > (which evidently works for others who have had success on 64k
kernels). I<br>> > have no idea what this means in practice (I don't know how to
introspect<br>> > it), but after making a tiny patch[1], everything came up smoothly
and I<br>> > was doing blazing-fast gzip (de)compression in no time.<br>> > <br>> > Everything seems to work fine on 4k pages. So, what's up? Are
there<br>> > pitfalls lurking around that I've yet to stumble over? More reasonably,<br>> > I'm curious as to why the feature supposedly depends on 64k pages,
or if<br>> > there's anything else I should be concerned about.<br><br>Will,<br><br>The reason I put in that config check is because we were only able to<br>test 64K pages at that point.<br><br>It is interesting that it is working for you. Following code in skiboot<br></span></tt><a href="https://github.com/open-power/skiboot/blob/master/hw/vas.c"><tt><span style=" font-size:10pt">https://github.com/open-power/skiboot/blob/master/hw/vas.c</span></tt></a><tt><span style=" font-size:10pt">should restrict<br>it to 64K pages. IIRC there is also a corresponding change in some NX <br>registers that should also be configured to allow 4K pages.<br><br><br>
static int init_north_ctl(struct proc_chip *chip)<br>
{<br>
uint64_t
val = 0ULL;<br><br>
val
= SETFIELD(VAS_64K_MODE_MASK, val, true);<br>
val
= SETFIELD(VAS_ACCEPT_PASTE_MASK, val, true);<br>
val
= SETFIELD(VAS_ENABLE_WC_MMIO_BAR, val, true);<br>
val
= SETFIELD(VAS_ENABLE_UWC_MMIO_BAR, val, true);<br>
val
= SETFIELD(VAS_ENABLE_RMA_MMIO_BAR, val, true);<br><br>
return
vas_scom_write(chip, VAS_MISC_N_CTL, val);<br>
}<br><br>I am copying Bulent Albali and Haren Myneni who have been working with<br>VAS/NX for their thoughts/experience.<br><br>> > <br>> <br>> Maybe ask Sukadev who did the implementation and is maintaining it
?<br>> <br>> > I do have to say I'm quite satisfied with the results of the
NX<br>> > accelerator, though. Being able to shuffle data to a RaptorCS
box over gigE<br>> > and get compressed data back faster than most software gzip could
ever<br>> > hope to achieve is no small feat, let alone the instantaneous
results locally.<br>> > :)<br>> > <br>> > Cheers,<br>> > Will Springer [she/her]<br>> > <br>> > [1]: </span></tt><a href="https://github.com/Skirmisher/void-packages/blob/vas-4k-pages/srcpkgs/linux5.9/patches/ppc-vas-on-4k.patch"><tt><span style=" font-size:10pt">https://github.com/Skirmisher/void-packages/blob/vas-4k-pages/srcpkgs/linux5.9/patches/ppc-vas-on-4k.patch</span></tt></a><tt><span style=" font-size:10pt"><br>> > <br>> <br>> <br>> Christophe<br></span></tt><br><br><BR>