From: Nicholas Piggin <npiggin@gmail.com> To: Haren Myneni <haren@linux.ibm.com>, herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au Cc: haren@us.ibm.com, hbabu@us.ibm.com Subject: Re: [PATCH v6 12/17] powerpc/pseries/vas: Integrate API with open/close windows Date: Sat, 19 Jun 2021 13:22:05 +1000 [thread overview] Message-ID: <1624072607.4axs4cpe7w.astroid@bobo.none> (raw) In-Reply-To: <0d6ca1ec553a61b219f42ebf6699dd6c56e2e978.camel@linux.ibm.com> Excerpts from Haren Myneni's message of June 18, 2021 5:49 pm: > On Fri, 2021-06-18 at 09:22 +1000, Nicholas Piggin wrote: >> Excerpts from Haren Myneni's message of June 18, 2021 6:36 am: >> > This patch adds VAS window allocatioa/close with the corresponding >> > hcalls. Also changes to integrate with the existing user space VAS >> > API and provide register/unregister functions to NX pseries driver. >> > >> > The driver register function is used to create the user space >> > interface (/dev/crypto/nx-gzip) and unregister to remove this >> > entry. >> > >> > The user space process opens this device node and makes an ioctl >> > to allocate VAS window. The close interface is used to deallocate >> > window. >> > >> > Signed-off-by: Haren Myneni <haren@linux.ibm.com> >> >> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> >> >> Unless there is some significant performance reason it might be >> simplest >> to take the mutex for the duration of the allocate and frees rather >> than >> taking it several times, covering the atomic with the lock instead. >> >> You have a big lock, might as well use it and not have to wonder what >> if >> things race here or there. > > Using mutex to protect allocate/deallocate window and setup/free IRQ, > also to protect updating the list. We do not need lock for modify > window hcall and other things. Hence taking mutex several times. Right, at which point you have to consider what happens with interleaving allocates and deallocates. I'm not saying it's wrong, just that if you do credential allocation, hcall allocation, irq allocation, and list insertion all under the one lock, and remoe it all under the one lock, concurrency requires less attention. > Also > used atomic for counters (used_lpar_creds) which can be exported in > sysfs (this patch will be added later in next enhancement seris). That's okay you can use mutexes for that too if that's how you're protecting them. > > Genarlly applications open window initially, do continuous copy/paste > operations and close window later. But possible that the library / > application to open/close window for each request. Also may be opening > or closing multiple windows (say 1000 depends on cores on the system) > at the same time. These cases may affect the application performance. It definitely could if you have a lot of concurrent open/close, but the code as is won't handle it all that well either, so there's the question of what is reasonable to do and what is reasonable to add concurrency complexity for. As I said, you've got it working and seem to have covered all cases now so let's get the series in first. But something to consider changing IMO. Thanks, Nick
WARNING: multiple messages have this Message-ID (diff)
From: Nicholas Piggin <npiggin@gmail.com> To: Haren Myneni <haren@linux.ibm.com>, herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au Subject: Re: [PATCH v6 12/17] powerpc/pseries/vas: Integrate API with open/close windows Date: Sat, 19 Jun 2021 13:22:05 +1000 [thread overview] Message-ID: <1624072607.4axs4cpe7w.astroid@bobo.none> (raw) In-Reply-To: <0d6ca1ec553a61b219f42ebf6699dd6c56e2e978.camel@linux.ibm.com> Excerpts from Haren Myneni's message of June 18, 2021 5:49 pm: > On Fri, 2021-06-18 at 09:22 +1000, Nicholas Piggin wrote: >> Excerpts from Haren Myneni's message of June 18, 2021 6:36 am: >> > This patch adds VAS window allocatioa/close with the corresponding >> > hcalls. Also changes to integrate with the existing user space VAS >> > API and provide register/unregister functions to NX pseries driver. >> > >> > The driver register function is used to create the user space >> > interface (/dev/crypto/nx-gzip) and unregister to remove this >> > entry. >> > >> > The user space process opens this device node and makes an ioctl >> > to allocate VAS window. The close interface is used to deallocate >> > window. >> > >> > Signed-off-by: Haren Myneni <haren@linux.ibm.com> >> >> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> >> >> Unless there is some significant performance reason it might be >> simplest >> to take the mutex for the duration of the allocate and frees rather >> than >> taking it several times, covering the atomic with the lock instead. >> >> You have a big lock, might as well use it and not have to wonder what >> if >> things race here or there. > > Using mutex to protect allocate/deallocate window and setup/free IRQ, > also to protect updating the list. We do not need lock for modify > window hcall and other things. Hence taking mutex several times. Right, at which point you have to consider what happens with interleaving allocates and deallocates. I'm not saying it's wrong, just that if you do credential allocation, hcall allocation, irq allocation, and list insertion all under the one lock, and remoe it all under the one lock, concurrency requires less attention. > Also > used atomic for counters (used_lpar_creds) which can be exported in > sysfs (this patch will be added later in next enhancement seris). That's okay you can use mutexes for that too if that's how you're protecting them. > > Genarlly applications open window initially, do continuous copy/paste > operations and close window later. But possible that the library / > application to open/close window for each request. Also may be opening > or closing multiple windows (say 1000 depends on cores on the system) > at the same time. These cases may affect the application performance. It definitely could if you have a lot of concurrent open/close, but the code as is won't handle it all that well either, so there's the question of what is reasonable to do and what is reasonable to add concurrency complexity for. As I said, you've got it working and seem to have covered all cases now so let's get the series in first. But something to consider changing IMO. Thanks, Nick
next prev parent reply other threads:[~2021-06-19 3:22 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-17 20:24 [PATCH v6 00/17] Enable VAS and NX-GZIP support on PowerVM Haren Myneni 2021-06-17 20:24 ` Haren Myneni 2021-06-17 20:29 ` [PATCH v6 01/17] powerpc/powernv/vas: Release reference to tgid during window close Haren Myneni 2021-06-17 20:29 ` Haren Myneni 2021-06-17 20:29 ` [PATCH v6 02/17] powerpc/vas: Move VAS API to book3s common platform Haren Myneni 2021-06-17 20:29 ` Haren Myneni 2021-06-17 20:30 ` [PATCH v6 03/17] powerpc/powernv/vas: Rename register/unregister functions Haren Myneni 2021-06-17 20:30 ` Haren Myneni 2021-06-17 20:31 ` [PATCH v6 04/17] powerpc/vas: Add platform specific user window operations Haren Myneni 2021-06-17 20:31 ` Haren Myneni 2021-06-17 23:27 ` Nicholas Piggin 2021-06-17 23:27 ` Nicholas Piggin 2021-06-17 20:31 ` [PATCH v6 05/17] powerpc/vas: Create take/drop pid and mm reference functions Haren Myneni 2021-06-17 20:31 ` Haren Myneni 2021-06-17 20:32 ` [PATCH v6 06/17] powerpc/vas: Move update_csb/dump_crb to common book3s platform Haren Myneni 2021-06-17 20:32 ` Haren Myneni 2021-06-17 23:10 ` Nicholas Piggin 2021-06-17 23:10 ` Nicholas Piggin 2021-06-17 20:33 ` [PATCH v6 07/17] powerpc/vas: Define and use common vas_window struct Haren Myneni 2021-06-17 20:33 ` Haren Myneni 2021-06-17 20:34 ` [PATCH v6 08/17] powerpc/pseries/vas: Define VAS/NXGZIP hcalls and structs Haren Myneni 2021-06-17 20:34 ` Haren Myneni 2021-06-17 20:34 ` [PATCH v6 09/17] powerpc/vas: Define QoS credit flag to allocate window Haren Myneni 2021-06-17 20:34 ` Haren Myneni 2021-06-17 20:35 ` [PATCH v6 10/17] powerpc/pseries/vas: Add hcall wrappers for VAS handling Haren Myneni 2021-06-17 20:35 ` Haren Myneni 2021-06-17 20:35 ` [PATCH v6 11/17] powerpc/pseries/vas: Implement getting capabilities from hypervisor Haren Myneni 2021-06-17 20:35 ` Haren Myneni 2021-06-17 23:24 ` Nicholas Piggin 2021-06-17 23:24 ` Nicholas Piggin 2021-06-17 20:36 ` [PATCH v6 12/17] powerpc/pseries/vas: Integrate API with open/close windows Haren Myneni 2021-06-17 20:36 ` Haren Myneni 2021-06-17 23:22 ` Nicholas Piggin 2021-06-17 23:22 ` Nicholas Piggin 2021-06-18 7:49 ` Haren Myneni 2021-06-18 7:49 ` Haren Myneni 2021-06-19 3:22 ` Nicholas Piggin [this message] 2021-06-19 3:22 ` Nicholas Piggin 2021-06-17 20:37 ` [PATCH v6 13/17] powerpc/pseries/vas: Setup IRQ and fault handling Haren Myneni 2021-06-17 20:37 ` Haren Myneni 2021-06-17 23:34 ` Nicholas Piggin 2021-06-17 23:34 ` Nicholas Piggin 2021-06-18 2:09 ` Haren Myneni 2021-06-18 2:09 ` Haren Myneni 2021-06-19 3:22 ` Nicholas Piggin 2021-06-19 3:22 ` Nicholas Piggin 2021-06-17 20:37 ` [PATCH v6 14/17] crypto/nx: Rename nx-842-pseries file name to nx-common-pseries Haren Myneni 2021-06-17 20:37 ` Haren Myneni 2021-06-17 20:38 ` [PATCH v6 15/17] crypto/nx: Get NX capabilities for GZIP coprocessor type Haren Myneni 2021-06-17 20:38 ` Haren Myneni 2021-06-17 23:35 ` Nicholas Piggin 2021-06-17 23:35 ` Nicholas Piggin 2021-06-17 20:39 ` [PATCH v6 16/17] crypto/nx: Add sysfs interface to export NX capabilities Haren Myneni 2021-06-17 20:39 ` Haren Myneni 2021-06-17 23:41 ` Nicholas Piggin 2021-06-17 23:41 ` Nicholas Piggin 2021-06-17 20:39 ` [PATCH v6 17/17] crypto/nx: Register and unregister VAS interface on PowerVM Haren Myneni 2021-06-17 20:39 ` Haren Myneni 2021-06-24 14:03 ` [PATCH v6 00/17] Enable VAS and NX-GZIP support " Michael Ellerman 2021-06-24 14:03 ` Michael Ellerman
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=1624072607.4axs4cpe7w.astroid@bobo.none \ --to=npiggin@gmail.com \ --cc=haren@linux.ibm.com \ --cc=haren@us.ibm.com \ --cc=hbabu@us.ibm.com \ --cc=herbert@gondor.apana.org.au \ --cc=linux-crypto@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mpe@ellerman.id.au \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.