From: kernel test robot <lkp@intel.com>
To: SJ Park <sj@kernel.org>
Cc: oe-kbuild-all@lists.linux.dev
Subject: [sj:damon/next 151/151] mm/damon/vaddr.c:196:13: warning: variable 'tidx' set but not used
Date: Sat, 11 Jul 2026 10:36:45 +0800 [thread overview]
Message-ID: <202607111055.NqcvApT6-lkp@intel.com> (raw)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/sj/linux.git damon/next
head: b617f1f8428697a2583fb6882864224d59a91bf2
commit: b617f1f8428697a2583fb6882864224d59a91bf2 [151/151] mm/damon/vaddr: remove debug message
config: m68k-allyesconfig (https://download.01.org/0day-ci/archive/20260711/202607111055.NqcvApT6-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260711/202607111055.NqcvApT6-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202607111055.NqcvApT6-lkp@intel.com/
All warnings (new ones prefixed by >>):
mm/damon/vaddr.c: In function '__damon_va_init_regions':
>> mm/damon/vaddr.c:196:13: warning: variable 'tidx' set but not used [-Wunused-but-set-variable=]
196 | int tidx = 0;
| ^~~~
vim +/tidx +196 mm/damon/vaddr.c
3f49584b262cf8 SeongJae Park 2021-09-07 148
3f49584b262cf8 SeongJae Park 2021-09-07 149 /*
3f49584b262cf8 SeongJae Park 2021-09-07 150 * Initialize the monitoring target regions for the given target (task)
3f49584b262cf8 SeongJae Park 2021-09-07 151 *
3f49584b262cf8 SeongJae Park 2021-09-07 152 * t the given target
3f49584b262cf8 SeongJae Park 2021-09-07 153 *
3f49584b262cf8 SeongJae Park 2021-09-07 154 * Because only a number of small portions of the entire address space
3f49584b262cf8 SeongJae Park 2021-09-07 155 * is actually mapped to the memory and accessed, monitoring the unmapped
3f49584b262cf8 SeongJae Park 2021-09-07 156 * regions is wasteful. That said, because we can deal with small noises,
3f49584b262cf8 SeongJae Park 2021-09-07 157 * tracking every mapping is not strictly required but could even incur a high
3f49584b262cf8 SeongJae Park 2021-09-07 158 * overhead if the mapping frequently changes or the number of mappings is
3f49584b262cf8 SeongJae Park 2021-09-07 159 * high. The adaptive regions adjustment mechanism will further help to deal
3f49584b262cf8 SeongJae Park 2021-09-07 160 * with the noise by simply identifying the unmapped areas as a region that
3f49584b262cf8 SeongJae Park 2021-09-07 161 * has no access. Moreover, applying the real mappings that would have many
3f49584b262cf8 SeongJae Park 2021-09-07 162 * unmapped areas inside will make the adaptive mechanism quite complex. That
3f49584b262cf8 SeongJae Park 2021-09-07 163 * said, too huge unmapped areas inside the monitoring target should be removed
3f49584b262cf8 SeongJae Park 2021-09-07 164 * to not take the time for the adaptive mechanism.
3f49584b262cf8 SeongJae Park 2021-09-07 165 *
3f49584b262cf8 SeongJae Park 2021-09-07 166 * For the reason, we convert the complex mappings to three distinct regions
3f49584b262cf8 SeongJae Park 2021-09-07 167 * that cover every mapped area of the address space. Also the two gaps
3f49584b262cf8 SeongJae Park 2021-09-07 168 * between the three regions are the two biggest unmapped areas in the given
3f49584b262cf8 SeongJae Park 2021-09-07 169 * address space. In detail, this function first identifies the start and the
3f49584b262cf8 SeongJae Park 2021-09-07 170 * end of the mappings and the two biggest unmapped areas of the address space.
3f49584b262cf8 SeongJae Park 2021-09-07 171 * Then, it constructs the three regions as below:
3f49584b262cf8 SeongJae Park 2021-09-07 172 *
3f49584b262cf8 SeongJae Park 2021-09-07 173 * [mappings[0]->start, big_two_unmapped_areas[0]->start)
3f49584b262cf8 SeongJae Park 2021-09-07 174 * [big_two_unmapped_areas[0]->end, big_two_unmapped_areas[1]->start)
3f49584b262cf8 SeongJae Park 2021-09-07 175 * [big_two_unmapped_areas[1]->end, mappings[nr_mappings - 1]->end)
3f49584b262cf8 SeongJae Park 2021-09-07 176 *
3f49584b262cf8 SeongJae Park 2021-09-07 177 * As usual memory map of processes is as below, the gap between the heap and
3f49584b262cf8 SeongJae Park 2021-09-07 178 * the uppermost mmap()-ed region, and the gap between the lowermost mmap()-ed
3f49584b262cf8 SeongJae Park 2021-09-07 179 * region and the stack will be two biggest unmapped regions. Because these
3f49584b262cf8 SeongJae Park 2021-09-07 180 * gaps are exceptionally huge areas in usual address space, excluding these
3f49584b262cf8 SeongJae Park 2021-09-07 181 * two biggest unmapped regions will be sufficient to make a trade-off.
3f49584b262cf8 SeongJae Park 2021-09-07 182 *
3f49584b262cf8 SeongJae Park 2021-09-07 183 * <heap>
3f49584b262cf8 SeongJae Park 2021-09-07 184 * <BIG UNMAPPED REGION 1>
3f49584b262cf8 SeongJae Park 2021-09-07 185 * <uppermost mmap()-ed region>
3f49584b262cf8 SeongJae Park 2021-09-07 186 * (other mmap()-ed regions and small unmapped regions)
3f49584b262cf8 SeongJae Park 2021-09-07 187 * <lowermost mmap()-ed region>
3f49584b262cf8 SeongJae Park 2021-09-07 188 * <BIG UNMAPPED REGION 2>
3f49584b262cf8 SeongJae Park 2021-09-07 189 * <stack>
3f49584b262cf8 SeongJae Park 2021-09-07 190 */
3f49584b262cf8 SeongJae Park 2021-09-07 191 static void __damon_va_init_regions(struct damon_ctx *ctx,
3f49584b262cf8 SeongJae Park 2021-09-07 192 struct damon_target *t)
3f49584b262cf8 SeongJae Park 2021-09-07 193 {
962fe7a6b1b2f9 SJ Park 2022-01-14 194 struct damon_target *ti;
3f49584b262cf8 SeongJae Park 2021-09-07 195 struct damon_addr_range regions[3];
442d87c7db9e9e SJ Park 2026-02-28 @196 int tidx = 0;
3f49584b262cf8 SeongJae Park 2021-09-07 197
3f49584b262cf8 SeongJae Park 2021-09-07 198 if (damon_va_three_regions(t, regions)) {
962fe7a6b1b2f9 SJ Park 2022-01-14 199 damon_for_each_target(ti, ctx) {
962fe7a6b1b2f9 SJ Park 2022-01-14 200 if (ti == t)
962fe7a6b1b2f9 SJ Park 2022-01-14 201 break;
962fe7a6b1b2f9 SJ Park 2022-01-14 202 tidx++;
962fe7a6b1b2f9 SJ Park 2022-01-14 203 }
3f49584b262cf8 SeongJae Park 2021-09-07 204 return;
3f49584b262cf8 SeongJae Park 2021-09-07 205 }
3f49584b262cf8 SeongJae Park 2021-09-07 206
442d87c7db9e9e SJ Park 2026-02-28 207 damon_set_regions(t, regions, 3, DAMON_MIN_REGION_SZ);
3f49584b262cf8 SeongJae Park 2021-09-07 208 }
3f49584b262cf8 SeongJae Park 2021-09-07 209
:::::: The code at line 196 was first introduced by commit
:::::: 442d87c7db9e9e2a569a49d38f404b8b556b8719 mm/damon/vaddr: do not split regions for min_nr_regions
:::::: TO: SeongJae Park <sj@kernel.org>
:::::: CC: Andrew Morton <akpm@linux-foundation.org>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next reply other threads:[~2026-07-11 2:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-11 2:36 kernel test robot [this message]
2026-07-11 3:43 ` [sj:damon/next 151/151] mm/damon/vaddr.c:196:13: warning: variable 'tidx' set but not used SJ Park
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=202607111055.NqcvApT6-lkp@intel.com \
--to=lkp@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=sj@kernel.org \
/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: link
Be 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.