<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">Hi all, any news on this matter?</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">Can a patch be submitted for evaluation?<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">Thanks,</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">Carlos<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 2, 2020 at 4:19 AM Will Springer <<a href="mailto:skirmisher@protonmail.com">skirmisher@protonmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tuesday, December 1, 2020 5:16:51 AM PST Bulent Abali wrote:<br>
> I don't know anything about VAS page size requirements in the kernel.  I<br>
> checked the user compression library and saw that we do a sysconf to<br>
> get the page size; so the library should be immune to page size by<br>
> design. But it wouldn't surprise me if a 64KB constant is inadvertently<br>
> hardcoded somewhere else in the library.  Giving heads up to Tulio and<br>
> Raphael who are owners of the github repo.<br>
> <br>
> <a href="https://github.com/libnxz/power-gzip/blob/master/lib/nx_zlib.c#L922" rel="noreferrer" target="_blank">https://github.com/libnxz/power-gzip/blob/master/lib/nx_zlib.c#L922</a><br>
> <br>
> If we got this wrong in the library it might manifest itself as an error<br>
> message of the sort "excessive page faults".  The library must touch<br>
> pages ahead to make them present in the memory; occasional page faults<br>
> is acceptable. It will retry.<br>
<br>
Hm, good to know. As I said I haven't noticed any problems so far, over a <br>
few different days of testing. My change is now in the Void Linux kernel <br>
package, and is working for others as well (including the Void maintainer <br>
Daniel/q66 who I CC'd initially).<br>
<br>
> <br>
> Bulent<br>
> <br>
> <br>
> <br>
> <br>
> From:        "Sukadev Bhattiprolu" <<a href="mailto:sukadev@linux.ibm.com" target="_blank">sukadev@linux.ibm.com</a>><br>
> To:        "Christophe Leroy" <<a href="mailto:christophe.leroy@csgroup.eu" target="_blank">christophe.leroy@csgroup.eu</a>><br>
> Cc:        "Will Springer" <<a href="mailto:skirmisher@protonmail.com" target="_blank">skirmisher@protonmail.com</a>>,<br>
> <a href="mailto:linuxppc-dev@lists.ozlabs.org" target="_blank">linuxppc-dev@lists.ozlabs.org</a>, <a href="mailto:daniel@octaforge.org" target="_blank">daniel@octaforge.org</a>, Bulent<br>
> Abali/Watson/IBM@IBM, <a href="mailto:haren@linux.ibm.com" target="_blank">haren@linux.ibm.com</a> Date:        12/01/2020 12:53<br>
> AM<br>
> Subject:        Re: CONFIG_PPC_VAS depends on 64k pages...?<br>
> <br>
> Christophe Leroy [<a href="mailto:christophe.leroy@csgroup.eu" target="_blank">christophe.leroy@csgroup.eu</a>] 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<br>
> > > 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<br>
> > > 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<br>
> > > size<br>
> > > dependency in the code, and suggested I try modifying the config to<br>
> > > switch it on. I did so, but was stopped by a minor complaint of an<br>
> > > "unexpected DT configuration" by the VAS code. I wasn't equipped to<br>
> > > figure out exactly what this meant, even after finding the<br>
> > > offending condition, so after writing a very drawn-out forum post<br>
> > > asking for help, I dropped the subject.<br>
> > > <br>
> > > Fast forward to today, when I was reminded of the whole thing again,<br>
> > > and decided to debug a bit further. Apparently the VAS platform<br>
> > > device (derived from the DT node) has 5 resources on my 4k kernel,<br>
> > > instead of 4 (which evidently works for others who have had success<br>
> > > on 64k kernels). I have no idea what this means in practice (I<br>
> > > don't know how to introspect it), but after making a tiny patch[1],<br>
> > > everything came up smoothly and I was doing blazing-fast gzip<br>
> > > (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<br>
> > > reasonably,<br>
> > > I'm curious as to why the feature supposedly depends on 64k pages,<br>
> > > or if 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>
> <a href="https://github.com/open-power/skiboot/blob/master/hw/vas.cshould" rel="noreferrer" target="_blank">https://github.com/open-power/skiboot/blob/master/hw/vas.cshould</a><br>
> restrict it to 64K pages. IIRC there is also a corresponding change in<br>
> some NX registers that should also be configured to allow 4K pages. <br>
<br>
Huh, that is interesting indeed. As far as the kernel code, the only thing <br>
specific to 64k pages I could find was in [1], where <br>
VAS_XLATE_LPCR_PAGE_SIZE is set. There is also NX_PAGE_SIZE in drivers/<br>
crypto/nx/nx.h, which is set to 4096, but I don't know if that's related to <br>
kernel page size at all. Without a better idea of the code base, I didn't<br>
examine more thoroughly.<br>
<br>
[1]: <a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/powerpc/platforms/powernv/vas-window.c#n293" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/powerpc/platforms/powernv/vas-window.c#n293</a><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,<br>
> true); val = SETFIELD(VAS_ACCEPT_PASTE_MASK, val, true); val =<br>
> SETFIELD(VAS_ENABLE_WC_MMIO_BAR, val, true); val =<br>
> SETFIELD(VAS_ENABLE_UWC_MMIO_BAR, val, true); val =<br>
> SETFIELD(VAS_ENABLE_RMA_MMIO_BAR, val, true);<br>
> <br>
>                                  return vas_scom_write(chip,<br>
> VAS_MISC_N_CTL, val); }<br>
> <br>
> I am copying Bulent Albali and Haren Myneni who have been working with<br>
> VAS/NX for their thoughts/experience.<br>
<br>
Thanks for this and for your input, by the way.<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<br>
> > > over gigE and get compressed data back faster than most software<br>
> > > gzip could ever hope to achieve is no small feat, let alone the<br>
> > > instantaneous results locally.> > <br>
> > > :)<br>
> > > <br>
> > > Cheers,<br>
> > > Will Springer [she/her]<br>
> > > <br>
> > > [1]:<br>
> > > <a href="https://github.com/Skirmisher/void-packages/blob/vas-4k-pages/srcpkgs/linux5.9/patches/ppc-vas-on-4k.patch" rel="noreferrer" target="_blank">https://github.com/Skirmisher/void-packages/blob/vas-4k-pages/srcpkgs/linux5.9/patches/ppc-vas-on-4k.patch</a><br>
> > Christophe<br>
<br>
Will [she/her]<br>
<br>
<br>
<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">________________________________________<br>Carlos Eduardo de Paula<br><a href="mailto:me@carlosedp.com" target="_blank">me@carlosedp.com</a><br><a href="http://carlosedp.com" target="_blank">http://carlosedp.com</a><br><a href="https://twitter.com/carlosedp" target="_blank">https://twitter.com/carlosedp</a><br><a href="https://www.linkedin.com/in/carlosedp/" target="_blank">https://www.linkedin.com/in/carlosedp/</a><br>________________________________________</div>