From: Can Guo <cang@codeaurora.org> To: Bean Huo <huobean@gmail.com> Cc: asutoshd@codeaurora.org, nguyenb@codeaurora.org, hongwus@codeaurora.org, linux-scsi@vger.kernel.org, kernel-team@android.com, Stanley Chu <stanley.chu@mediatek.com>, Alim Akhtar <alim.akhtar@samsung.com>, Avri Altman <avri.altman@wdc.com>, "James E.J. Bottomley" <jejb@linux.ibm.com>, "Martin K. Petersen" <martin.petersen@oracle.com>, Matthias Brugger <matthias.bgg@gmail.com>, Bean Huo <beanhuo@micron.com>, Jaegeuk Kim <jaegeuk@kernel.org>, Adrian Hunter <adrian.hunter@intel.com>, Kiwoong Kim <kwmad.kim@samsung.com>, Satya Tangirala <satyat@google.com>, open list <linux-kernel@vger.kernel.org>, "moderated list:ARM/Mediatek SoC support" <linux-arm-kernel@lists.infradead.org>, "moderated list:ARM/Mediatek SoC support" <linux-mediatek@lists.infradead.org> Subject: Re: [PATCH v1 2/3] scsi: ufs: Optimize host lock on transfer requests send/compl paths Date: Wed, 02 Jun 2021 10:14:39 +0800 [thread overview] Message-ID: <adc85803e27226bc8d24c53061e39214@codeaurora.org> (raw) In-Reply-To: <6d6d296a84f1e62f65fda4d172a85bb35d9a3684.camel@gmail.com> Hi Bean, On 2021-06-01 00:04, Bean Huo wrote: > On Mon, 2021-05-24 at 01:36 -0700, Can Guo wrote: >> Current UFS IRQ handler is completely wrapped by host lock, and >> because >> >> ufshcd_send_command() is also protected by host lock, when IRQ >> handler >> >> fires, not only the CPU running the IRQ handler cannot send new >> requests, >> >> the rest CPUs can neither. Move the host lock wrapping the IRQ >> handler into >> >> specific branches, i.e., ufshcd_uic_cmd_compl(), >> ufshcd_check_errors(), >> >> ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to >> further >> >> reduce occpuation of host lock in ufshcd_transfer_req_compl(), host >> lock is >> >> no longer required to call __ufshcd_transfer_req_compl(). As per >> test, the >> >> optimization can bring considerable gain to random read/write >> performance. >> >> >> >> Cc: Stanley Chu <stanley.chu@mediatek.com> >> >> Co-developed-by: Asutosh Das <asutoshd@codeaurora.org> >> >> Signed-off-by: Asutosh Das <asutoshd@codeaurora.org> >> >> Signed-off-by: Can Guo <cang@codeaurora.org> > > Can, > The patch looks good to me. > I did a UFS queue limitation test before, observed that once the queue > is full, then the active task number in the queue will get down. For > the Nvme, the scenario is the same. You can refer to the slide 23, and > slide 24 in the pdf: > https://elinux.org/images/6/6c/Linux_Storage_System_Bottleneck_Exploration_V0.3.pdf > I don't know if your patch can fix this > issue. I've studied these slides made by you many times, it is really good. I will do some study later on this. Thanks for the slides. > > Unfortunately, I cannot verify UTRLCNR usage flow since my platform is > v2.1. But at least my test can prove that the patch doesn't impact the > legacy(UFSHCI is less than v3.0) doorbell usage flow. > Thanks for your time :). Regards, Can Guo. > Reviewed-by: Bean Huo <beanhuo@micron.com> > > > Bean
WARNING: multiple messages have this Message-ID (diff)
From: Can Guo <cang@codeaurora.org> To: Bean Huo <huobean@gmail.com> Cc: asutoshd@codeaurora.org, nguyenb@codeaurora.org, hongwus@codeaurora.org, linux-scsi@vger.kernel.org, kernel-team@android.com, Stanley Chu <stanley.chu@mediatek.com>, Alim Akhtar <alim.akhtar@samsung.com>, Avri Altman <avri.altman@wdc.com>, "James E.J. Bottomley" <jejb@linux.ibm.com>, "Martin K. Petersen" <martin.petersen@oracle.com>, Matthias Brugger <matthias.bgg@gmail.com>, Bean Huo <beanhuo@micron.com>, Jaegeuk Kim <jaegeuk@kernel.org>, Adrian Hunter <adrian.hunter@intel.com>, Kiwoong Kim <kwmad.kim@samsung.com>, Satya Tangirala <satyat@google.com>, open list <linux-kernel@vger.kernel.org>, "moderated list:ARM/Mediatek SoC support" <linux-arm-kernel@lists.infradead.org>, "moderated list:ARM/Mediatek SoC support" <linux-mediatek@lists.infradead.org> Subject: Re: [PATCH v1 2/3] scsi: ufs: Optimize host lock on transfer requests send/compl paths Date: Wed, 02 Jun 2021 10:14:39 +0800 [thread overview] Message-ID: <adc85803e27226bc8d24c53061e39214@codeaurora.org> (raw) In-Reply-To: <6d6d296a84f1e62f65fda4d172a85bb35d9a3684.camel@gmail.com> Hi Bean, On 2021-06-01 00:04, Bean Huo wrote: > On Mon, 2021-05-24 at 01:36 -0700, Can Guo wrote: >> Current UFS IRQ handler is completely wrapped by host lock, and >> because >> >> ufshcd_send_command() is also protected by host lock, when IRQ >> handler >> >> fires, not only the CPU running the IRQ handler cannot send new >> requests, >> >> the rest CPUs can neither. Move the host lock wrapping the IRQ >> handler into >> >> specific branches, i.e., ufshcd_uic_cmd_compl(), >> ufshcd_check_errors(), >> >> ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to >> further >> >> reduce occpuation of host lock in ufshcd_transfer_req_compl(), host >> lock is >> >> no longer required to call __ufshcd_transfer_req_compl(). As per >> test, the >> >> optimization can bring considerable gain to random read/write >> performance. >> >> >> >> Cc: Stanley Chu <stanley.chu@mediatek.com> >> >> Co-developed-by: Asutosh Das <asutoshd@codeaurora.org> >> >> Signed-off-by: Asutosh Das <asutoshd@codeaurora.org> >> >> Signed-off-by: Can Guo <cang@codeaurora.org> > > Can, > The patch looks good to me. > I did a UFS queue limitation test before, observed that once the queue > is full, then the active task number in the queue will get down. For > the Nvme, the scenario is the same. You can refer to the slide 23, and > slide 24 in the pdf: > https://elinux.org/images/6/6c/Linux_Storage_System_Bottleneck_Exploration_V0.3.pdf > I don't know if your patch can fix this > issue. I've studied these slides made by you many times, it is really good. I will do some study later on this. Thanks for the slides. > > Unfortunately, I cannot verify UTRLCNR usage flow since my platform is > v2.1. But at least my test can prove that the patch doesn't impact the > legacy(UFSHCI is less than v3.0) doorbell usage flow. > Thanks for your time :). Regards, Can Guo. > Reviewed-by: Bean Huo <beanhuo@micron.com> > > > Bean _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
next prev parent reply other threads:[~2021-06-02 2:14 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-24 8:36 [PATCH v1 0/3] Optimize host lock on TR send/compl paths and utilize UTRLCNR Can Guo 2021-05-24 8:36 ` [PATCH v1 1/3] scsi: ufs: Remove a redundant command completion logic in error handler Can Guo 2021-05-24 16:43 ` Bart Van Assche 2021-05-25 4:15 ` Stanley Chu 2021-05-31 7:14 ` Bean Huo 2021-05-24 8:36 ` [PATCH v1 2/3] scsi: ufs: Optimize host lock on transfer requests send/compl paths Can Guo 2021-05-24 8:36 ` Can Guo 2021-05-24 8:36 ` Can Guo 2021-05-24 11:25 ` kernel test robot 2021-05-24 11:25 ` kernel test robot 2021-06-08 17:53 ` Nathan Chancellor 2021-06-08 17:53 ` Nathan Chancellor 2021-06-09 1:01 ` Can Guo 2021-06-09 1:01 ` Can Guo 2021-05-24 20:10 ` Bart Van Assche 2021-05-24 20:10 ` Bart Van Assche 2021-05-24 20:10 ` Bart Van Assche 2021-05-25 1:34 ` Asutosh Das (asd) 2021-05-25 1:34 ` Asutosh Das (asd) 2021-05-25 8:24 ` Avri Altman 2021-05-25 8:24 ` Avri Altman 2021-05-25 8:24 ` Avri Altman 2021-05-28 7:30 ` Avri Altman 2021-05-28 7:30 ` Avri Altman 2021-05-28 7:30 ` Avri Altman 2021-06-02 21:18 ` Asutosh Das (asd) 2021-06-02 21:18 ` Asutosh Das (asd) 2021-05-25 1:40 ` Can Guo 2021-05-25 1:40 ` Can Guo 2021-05-25 16:40 ` Bart Van Assche 2021-05-25 16:40 ` Bart Van Assche 2021-05-25 16:40 ` Bart Van Assche 2021-05-31 16:04 ` Bean Huo 2021-05-31 16:04 ` Bean Huo 2021-05-31 16:04 ` Bean Huo 2021-06-02 2:14 ` Can Guo [this message] 2021-06-02 2:14 ` Can Guo 2021-06-03 0:18 ` Bart Van Assche 2021-06-03 0:18 ` Bart Van Assche 2021-06-03 0:18 ` Bart Van Assche 2021-06-03 2:54 ` Stanley Chu 2021-06-03 2:54 ` Stanley Chu 2021-06-03 2:54 ` Stanley Chu 2021-06-04 1:49 ` Can Guo 2021-06-04 1:49 ` Can Guo 2021-06-17 2:49 ` Bart Van Assche 2021-06-17 2:49 ` Bart Van Assche 2021-06-17 2:49 ` Bart Van Assche 2021-06-23 2:04 ` Can Guo 2021-06-23 2:04 ` Can Guo 2021-06-28 22:58 ` Bart Van Assche 2021-06-28 22:58 ` Bart Van Assche 2021-06-28 22:58 ` Bart Van Assche 2021-06-29 5:41 ` Can Guo 2021-06-29 5:41 ` Can Guo 2021-07-01 15:57 ` Bart Van Assche 2021-07-01 15:57 ` Bart Van Assche 2021-07-01 15:57 ` Bart Van Assche 2021-05-24 8:36 ` [PATCH v1 3/3] scsi: ufs: Utilize Transfer Request List Completion Notification Register Can Guo 2021-05-24 8:36 ` Can Guo 2021-05-24 8:36 ` Can Guo 2021-05-31 16:05 ` Bean Huo 2021-05-31 16:05 ` Bean Huo 2021-05-31 16:05 ` Bean Huo 2021-06-03 2:54 ` Stanley Chu 2021-06-03 2:54 ` Stanley Chu 2021-06-03 2:54 ` Stanley Chu 2021-06-16 3:48 ` [PATCH v1 0/3] Optimize host lock on TR send/compl paths and utilize UTRLCNR Martin K. Petersen
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=adc85803e27226bc8d24c53061e39214@codeaurora.org \ --to=cang@codeaurora.org \ --cc=adrian.hunter@intel.com \ --cc=alim.akhtar@samsung.com \ --cc=asutoshd@codeaurora.org \ --cc=avri.altman@wdc.com \ --cc=beanhuo@micron.com \ --cc=hongwus@codeaurora.org \ --cc=huobean@gmail.com \ --cc=jaegeuk@kernel.org \ --cc=jejb@linux.ibm.com \ --cc=kernel-team@android.com \ --cc=kwmad.kim@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mediatek@lists.infradead.org \ --cc=linux-scsi@vger.kernel.org \ --cc=martin.petersen@oracle.com \ --cc=matthias.bgg@gmail.com \ --cc=nguyenb@codeaurora.org \ --cc=satyat@google.com \ --cc=stanley.chu@mediatek.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: 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.