lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZMICQ52W8HTUpvTX@li-bb2b2a4c-3307-11b2-a85c-8fa5c3a69313.ibm.com>
Date:   Thu, 27 Jul 2023 11:06:03 +0530
From:   Ojaswin Mujoo <ojaswin@...ux.ibm.com>
To:     Kemeng Shi <shikemeng@...weicloud.com>
Cc:     tytso@....edu, adilger.kernel@...ger.ca, ritesh.list@...il.com,
        linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 10/10] ext4: correct some stale comment of criteria

On Thu, Jul 27, 2023 at 09:29:11AM +0800, Kemeng Shi wrote:
> 
> 
> on 7/26/2023 10:50 PM, Ojaswin Mujoo wrote:
> > On Wed, Jul 26, 2023 at 02:51:06AM +0800, Kemeng Shi wrote:
> >> We named criteria with CR_XXX, correct stale comment to criteria with
> >> raw number.
> > 
> > Hi Kemeng,
> > 
> > Thanks for the cleanups.
> > 
> >>
> >> Fixes: f52f3d2b9fba ("ext4: Give symbolic names to mballoc criterias")
> >> Signed-off-by: Kemeng Shi <shikemeng@...weicloud.com>
> >> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@...il.com>
> >> ---
> >>  fs/ext4/mballoc.c | 8 ++++----
> >>  1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> >> index 36eea63eaace..de5da76e6748 100644
> >> --- a/fs/ext4/mballoc.c
> >> +++ b/fs/ext4/mballoc.c
> >> @@ -2777,8 +2777,8 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
> >>  
> >>  	/*
> >>  	 * ac->ac_2order is set only if the fe_len is a power of 2
> >> -	 * if ac->ac_2order is set we also set criteria to 0 so that we
> >> -	 * try exact allocation using buddy.
> >> +	 * if ac->ac_2order is set we also set criteria to CR_POWER2_ALIGNED
> >> +	 * so that we try exact allocation using buddy.
> >>  	 */
> >>  	i = fls(ac->ac_g_ex.fe_len);
> >>  	ac->ac_2order = 0;
> >> @@ -2835,8 +2835,8 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
> >>  			/*
> >>  			 * Batch reads of the block allocation bitmaps
> >>  			 * to get multiple READs in flight; limit
> >> -			 * prefetching at cr=0/1, otherwise mballoc can
> >> -			 * spend a lot of time loading imperfect groups
> >> +			 * prefetching at cr below CR_FAST, otherwise mballoc
> > 
> > One of my earlier patchset has replaced the CR_FAST macro with
> > ext4_mb_cr_expensive() so maybe we can account for that here:
> > 
> > https://lore.kernel.org/linux-ext4/20230630085927.140137-1-ojaswin@linux.ibm.com/
> > 
> Hi Ojaswin, sorry for missing this. I still could not find the comment update
> of stale comment "limit prefetching at cr=0/1" in that patch. Maybe we could
> update comment to "prefetching at inexpensive CR, otherwise ...". What do
> you think. Or did I miss anything.

Hey Kemeng,

That's right I missed the update but just wanted to let you know that
CR_FAST would be removed. "prefetching at inexpensive CRs, ..."  sounds
good to me.

Regards,
ojaswin
> 
> -- 
> Best wishes
> Kemeng Shi
> > Regards,
> > ojaswin
> > 
> >> +			 * can spend a lot of time loading imperfect groups
> > 
> >>  			 */
> >>  			if ((prefetch_grp == group) &&
> >>  			    (cr >= CR_FAST ||
> >> -- 
> >> 2.30.0
> >>
> >
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ