linux-kernel - Re: [PATCH] xfs: add tunable threshold parameter for triggering zone GC

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <67c0a5f9-3349-4910-85f9-a017b6499dd3@roeck-us.net>
Date: Sun, 20 Apr 2025 12:13:34 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Carlos Maiolino <cem@...nel.org>
Cc: Hans Holmberg <Hans.Holmberg@....com>, Dave Chinner
 <david@...morbit.com>, "Darrick J . Wong" <djwong@...nel.org>,
 hch <hch@....de>, "linux-xfs@...r.kernel.org" <linux-xfs@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] xfs: add tunable threshold parameter for triggering zone
 GC

On 4/20/25 11:07, Carlos Maiolino wrote:
...
>>
>> diff --git a/fs/xfs/xfs_zone_gc.c b/fs/xfs/xfs_zone_gc.c
>> index 8c541ca71872..6dde2a680e75 100644
>> --- a/fs/xfs/xfs_zone_gc.c
>> +++ b/fs/xfs/xfs_zone_gc.c
>> @@ -170,7 +170,7 @@ bool
>>    xfs_zoned_need_gc(
>>           struct xfs_mount        *mp)
>>    {
>> -       s64                     available, free;
>> +       u64                     available, free, rem;
>>
>>           if (!xfs_group_marked(mp, XG_TYPE_RTG, XFS_RTG_RECLAIMABLE))
>>                   return false;
>> @@ -183,7 +183,12 @@ xfs_zoned_need_gc(
>>                   return true;
>>
>>           free = xfs_estimate_freecounter(mp, XC_FREE_RTEXTENTS);
>> -       if (available < mult_frac(free, mp->m_zonegc_low_space, 100))
>> +
>> +       rem = do_div(free, 100);
>> +       free = free * mp->m_zonegc_low_space +
>> +               div_u64(rem * mp->m_zonegc_low_space, 100);
>> +
>> +       if (available < free)
>>                   return true;
> 
> You're essentially open coding mult_frac(), if we can get mult_frac() to work
> on 64-bit too (or add a 64-bit version), that seems a better generic solution.
> 

Yes, I know. Problem is that getting more than one maintainer involved tends to make
it exponentially more difficult to get anything accepted. With that in mind, I prefer
open coded solutions like the one I suggested above. A generic solution is then still
possible, but it is disconnected from solving the immediate problem.

Guenter