From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Will Springer <skirmisher@protonmail.com>,
linuxppc-dev@lists.ozlabs.org,
Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Cc: daniel@octaforge.org
Subject: Re: CONFIG_PPC_VAS depends on 64k pages...?
Date: Thu, 19 Nov 2020 15:43:39 +0100 [thread overview]
Message-ID: <2b234a7e-e9f6-d02b-a20f-74c0cc1df8d3@csgroup.eu> (raw)
In-Reply-To: <7171078.EvYhyI6sBW@sheen>
Hi,
Le 19/11/2020 à 11:58, Will Springer a écrit :
> I learned about the POWER9 gzip accelerator a few months ago when the
> support hit upstream Linux 5.8. However, for some reason the Kconfig
> dictates that VAS depends on a 64k page size, which is problematic as I
> run Void Linux, which uses a 4k-page kernel.
>
> Some early poking by others indicated there wasn't an obvious page size
> dependency in the code, and suggested I try modifying the config to switch
> it on. I did so, but was stopped by a minor complaint of an "unexpected DT
> configuration" by the VAS code. I wasn't equipped to figure out exactly what
> this meant, even after finding the offending condition, so after writing a
> very drawn-out forum post asking for help, I dropped the subject.
>
> Fast forward to today, when I was reminded of the whole thing again, and
> decided to debug a bit further. Apparently the VAS platform device
> (derived from the DT node) has 5 resources on my 4k kernel, instead of 4
> (which evidently works for others who have had success on 64k kernels). I
> have no idea what this means in practice (I don't know how to introspect
> it), but after making a tiny patch[1], everything came up smoothly and I
> was doing blazing-fast gzip (de)compression in no time.
>
> Everything seems to work fine on 4k pages. So, what's up? Are there
> pitfalls lurking around that I've yet to stumble over? More reasonably,
> I'm curious as to why the feature supposedly depends on 64k pages, or if
> there's anything else I should be concerned about.
>
Maybe ask Sukadev who did the implementation and is maintaining it ?
> I do have to say I'm quite satisfied with the results of the NX
> accelerator, though. Being able to shuffle data to a RaptorCS box over gigE
> and get compressed data back faster than most software gzip could ever
> hope to achieve is no small feat, let alone the instantaneous results locally.
> :)
>
> Cheers,
> Will Springer [she/her]
>
> [1]: https://github.com/Skirmisher/void-packages/blob/vas-4k-pages/srcpkgs/linux5.9/patches/ppc-vas-on-4k.patch
>
Christophe
next prev parent reply other threads:[~2020-11-19 14:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-19 10:58 CONFIG_PPC_VAS depends on 64k pages...? Will Springer
2020-11-19 14:43 ` Christophe Leroy [this message]
2020-12-01 5:52 ` Sukadev Bhattiprolu
2020-12-01 13:16 ` Bulent Abali
2020-12-02 7:17 ` Will Springer
2021-01-15 13:54 ` Carlos Eduardo de Paula
2020-12-01 21:05 ` Carlos Eduardo de Paula
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2b234a7e-e9f6-d02b-a20f-74c0cc1df8d3@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=daniel@octaforge.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=skirmisher@protonmail.com \
--cc=sukadev@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).