On 2021/3/17 8:27, Mike Kravetz wrote: > On 3/15/21 11:49 PM, Miaohe Lin wrote: >> On 2021/3/16 11:07, Mike Kravetz wrote: >>> On 3/15/21 7:27 PM, Miaohe Lin wrote: >>>> The fault_mutex hashing overhead can be avoided in truncate_op case >>>> because page faults can not race with truncation in this routine. So >>>> calculate hash for fault_mutex only in !truncate_op case to save some cpu >>>> cycles. >>>> >>>> Reviewed-by: Mike Kravetz <mike.krav...@oracle.com> >>>> Signed-off-by: Miaohe Lin <linmia...@huawei.com> >>>> Cc: Mike Kravetz <mike.krav...@oracle.com> >>>> --- >>>> v1->v2: >>>> remove unnecessary initialization for variable hash >>>> collect Reviewed-by tag from Mike Kravetz >>> >>> My apologies for not replying sooner and any misunderstanding from my >>> previous comments. >>> >> >> That's all right. >> >>> If the compiler is going to produce a warning because the variable is >>> not initialized, then we will need to keep the initialization. >>> Otherwise, this will show up as a build regression. Ideally, there >>> would be a modifier which could be used to tell the compiler the >>> variable will used. I do not know if such a modifier exists. >>> >> >> I do not know if such a modifier exists too. But maybe not all compilers are >> intelligent >> enough to not produce a warning. It would be safe to keep the >> initialization... >> >>> The patch can not produce a new warning. So, if you need to initialize >> >> So just drop this version of the patch? Or should I send a new version with >> your Reviewed-by tag and >> keep the initialization? >> > > Yes, drop this version of the patch. You can add my Reviewed-by to the > previous version that included the initialization and resend. >
Will do. Many thanks. :) > All the cleanup patches in this series should be good to go. >
