From: Can Guo <cang@codeaurora.org> To: Bart Van Assche <bvanassche@acm.org> 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: Tue, 29 Jun 2021 13:41:53 +0800 [thread overview] Message-ID: <464097469b09752ce4ebb38c08f1a94a@codeaurora.org> (raw) In-Reply-To: <c31185f5-e816-937d-25ac-1657b6111ff8@acm.org> On 2021-06-29 06:58, Bart Van Assche wrote: > On 5/24/21 1:36 AM, 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. > > Hi Can, > > Since this patch has been applied on the AOSP kernel we see 100% > reproducible lockups appearing on multiple test setups. Examples of > call > traces: > > blk_execute_rq() > __scsi_execute() > sd_sync_cache() > sd_suspend_common() > sd_suspend_system() > scsi_bus_suspend() > __device_suspend() > > blk_execute_rq() > __scsi_execute() > ufshcd_clear_ua_wlun() > ufshcd_err_handling_unprepare() > ufshcd_err_handler() > process_one_work() > > Reverting this patch and the next patch from this series solved the > lockups. Do you prefer to revert this patch or do you perhaps want us > to > test a potential fix? > Hi Bart, I am waiting for more infos/logs/dumps on Buganizor to look into it. With above calltrace snippet, it is hard to figure out what is happening. Besides, we've tested this series before go upstream and we didn't see such problem. Thanks, Can Guo. > Thanks, > > Bart.
WARNING: multiple messages have this Message-ID (diff)
From: Can Guo <cang@codeaurora.org> To: Bart Van Assche <bvanassche@acm.org> 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: Tue, 29 Jun 2021 13:41:53 +0800 [thread overview] Message-ID: <464097469b09752ce4ebb38c08f1a94a@codeaurora.org> (raw) In-Reply-To: <c31185f5-e816-937d-25ac-1657b6111ff8@acm.org> On 2021-06-29 06:58, Bart Van Assche wrote: > On 5/24/21 1:36 AM, 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. > > Hi Can, > > Since this patch has been applied on the AOSP kernel we see 100% > reproducible lockups appearing on multiple test setups. Examples of > call > traces: > > blk_execute_rq() > __scsi_execute() > sd_sync_cache() > sd_suspend_common() > sd_suspend_system() > scsi_bus_suspend() > __device_suspend() > > blk_execute_rq() > __scsi_execute() > ufshcd_clear_ua_wlun() > ufshcd_err_handling_unprepare() > ufshcd_err_handler() > process_one_work() > > Reverting this patch and the next patch from this series solved the > lockups. Do you prefer to revert this patch or do you perhaps want us > to > test a potential fix? > Hi Bart, I am waiting for more infos/logs/dumps on Buganizor to look into it. With above calltrace snippet, it is hard to figure out what is happening. Besides, we've tested this series before go upstream and we didn't see such problem. Thanks, Can Guo. > Thanks, > > Bart. _______________________________________________ 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-29 5:42 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 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 [this message] 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=464097469b09752ce4ebb38c08f1a94a@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=bvanassche@acm.org \ --cc=hongwus@codeaurora.org \ --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.