on 3/28/2024 9:59 AM, Kemeng Shi wrote:
>
> on 3/28/2024 1:40 AM, Andrew Morton wrote:
>> On Wed, 27 Mar 2024 23:57:45 +0800 Kemeng Shi <shikemeng@xxxxxxxxxxxxxxx> wrote:
>>
>>> This series tries to improve visilibity of writeback.
>>
>> Well... why? Is anyone usefully using the existing instrumentation?
>> What is to be gained by expanding it further? What is the case for
>> adding this code?
>>
>> I don't recall hearing of anyone using the existing debug
>> instrumentation so perhaps we should remove it!
> Hi Andrew, this was discussed in [1]. In short, I use the
> debug files to test change in submit patchset [1]. The
> wb_monitor.py is suggested by Tejun in [2] to improve
> visibility of writeback.
> I use the debug files to test change in [1]. The wb_monitor.py is suggested by Tejun
> in [2] to improve visibility of writeback.
>>
>> Also, I hit a build error and a pile of warnings with an arm
>> allnoconfig build.
With arm allnoconfig build on uptodated mm-unstable branch, I don't
hit any build error but only some warnings as following:
...
mm/page-writeback.c: In function ‘cgwb_calc_thresh’:
mm/page-writeback.c:906:13: warning: ‘writeback’ is used uninitialized in this function [-Wuninitialized]
906 | mdtc.dirty += writeback;
| ~~~~~~~~~~~^~~~~~~~~~~~
In file included from ./include/linux/kernel.h:28,
from mm/page-writeback.c:15:
./include/linux/minmax.h:46:54: warning: ‘filepages’ is used uninitialized in this function [-Wuninitialized]
46 | #define __cmp(op, x, y) ((x) __cmp_op_##op (y) ? (x) : (y))
| ^
mm/page-writeback.c:898:16: note: ‘filepages’ was declared here
898 | unsigned long filepages, headroom, writeback;
| ^~~~~~~~~
In file included from ./include/linux/kernel.h:28,
from mm/page-writeback.c:15:
./include/linux/minmax.h:46:54: warning: ‘headroom’ is used uninitialized in this function [-Wuninitialized]
46 | #define __cmp(op, x, y) ((x) __cmp_op_##op (y) ? (x) : (y))
| ^
mm/page-writeback.c:898:27: note: ‘headroom’ was declared here
898 | unsigned long filepages, headroom, writeback;
| ^~~~~~~~
...
The only reason I can think of is that I also apply patchset [1]
for build. I mentioned patchset [1] in cover letter but I forgot
to notify the dependency to the patchset.
If this is the reason to blame for buidl error, I will send a new
set based on mm-unstable in next version.
Thanks,
Kemeng
[1] https://lore.kernel.org/lkml/20240123183332.876854-1-shikemeng@xxxxxxxxxxxxxxx/T/#mc6455784a63d0f8aa1a2f5aff325abcdf9336b76
>>
> Sorry for this, I only tested on x86. I will look into this and
> fix the build problem in next version.
>
> [1] https://lore.kernel.org/lkml/44e3b910-8b52-5583-f8a9-37105bf5e5b6@xxxxxxxxxxxxxxx/
> [2] https://lore.kernel.org/lkml/a747dc7d-f24a-08bd-d969-d3fb35e151b7@xxxxxxxxxxxxxxx/
> [3] https://lore.kernel.org/lkml/ZcUsOb_fyvYr-zZ-@xxxxxxxxxxxxxxx/
>
