| 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
| ||
|
Message-ID: <202101171522.nVe5ebky-lkp@intel.com>
Date: Sun, 17 Jan 2021 15:11:54 +0800
From: kernel test robot <lkp@...el.com>
To: Dongdong Tao <tdd21151186@...il.com>, colyli@...e.de
Cc: kbuild-all@...ts.01.org, dongdong tao <dongdong.tao@...onical.com>,
Kent Overstreet <kmo@...erainc.com>,
linux-bcache@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bcache: consider the fragmentation when update the
writeback rate
Hi Dongdong,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Dongdong-Tao/bcache-consider-the-fragmentation-when-update-the-writeback-rate/20210105-110903
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62
config: i386-randconfig-a002-20200806 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# https://github.com/0day-ci/linux/commit/7777fef68d1401235db42dd0d59c5c3dba3d42d3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Dongdong-Tao/bcache-consider-the-fragmentation-when-update-the-writeback-rate/20210105-110903
git checkout 7777fef68d1401235db42dd0d59c5c3dba3d42d3
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@...el.com>
All errors (new ones prefixed by >>):
ld: drivers/md/bcache/writeback.o: in function `__update_writeback_rate':
>> drivers/md/bcache/writeback.c:106: undefined reference to `__divdi3'
>> ld: drivers/md/bcache/writeback.c:120: undefined reference to `__divdi3'
vim +106 drivers/md/bcache/writeback.c
60
61 static void __update_writeback_rate(struct cached_dev *dc)
62 {
63 /*
64 * PI controller:
65 * Figures out the amount that should be written per second.
66 *
67 * First, the error (number of sectors that are dirty beyond our
68 * target) is calculated. The error is accumulated (numerically
69 * integrated).
70 *
71 * Then, the proportional value and integral value are scaled
72 * based on configured values. These are stored as inverses to
73 * avoid fixed point math and to make configuration easy-- e.g.
74 * the default value of 40 for writeback_rate_p_term_inverse
75 * attempts to write at a rate that would retire all the dirty
76 * blocks in 40 seconds.
77 *
78 * The writeback_rate_i_inverse value of 10000 means that 1/10000th
79 * of the error is accumulated in the integral term per second.
80 * This acts as a slow, long-term average that is not subject to
81 * variations in usage like the p term.
82 */
83 int64_t target = __calc_target_rate(dc);
84 int64_t dirty = bcache_dev_sectors_dirty(&dc->disk);
85 int64_t error = dirty - target;
86 int64_t proportional_scaled =
87 div_s64(error, dc->writeback_rate_p_term_inverse);
88 int64_t integral_scaled;
89 uint32_t new_rate;
90
91 /*
92 * We need to consider the number of dirty buckets as well
93 * when calculating the proportional_scaled, Otherwise we might
94 * have an unreasonable small writeback rate at a highly fragmented situation
95 * when very few dirty sectors consumed a lot dirty buckets, the
96 * worst case is when dirty_data reached writeback_percent and
97 * dirty buckets reached to cutoff_writeback_sync, but the rate
98 * still will be at the minimum value, which will cause the write
99 * stuck at a non-writeback mode.
100 */
101 struct cache_set *c = dc->disk.c;
102
103 int64_t dirty_buckets = c->nbuckets - c->avail_nbuckets;
104
105 if (c->gc_stats.in_use > BCH_WRITEBACK_FRAGMENT_THRESHOLD_LOW && dirty > 0) {
> 106 int64_t fragment = (dirty_buckets * c->cache->sb.bucket_size) / dirty;
107 int64_t fp_term;
108 int64_t fps;
109
110 if (c->gc_stats.in_use <= BCH_WRITEBACK_FRAGMENT_THRESHOLD_MID) {
111 fp_term = dc->writeback_rate_fp_term_low *
112 (c->gc_stats.in_use - BCH_WRITEBACK_FRAGMENT_THRESHOLD_LOW);
113 } else if (c->gc_stats.in_use <= BCH_WRITEBACK_FRAGMENT_THRESHOLD_HIGH) {
114 fp_term = dc->writeback_rate_fp_term_mid *
115 (c->gc_stats.in_use - BCH_WRITEBACK_FRAGMENT_THRESHOLD_MID);
116 } else {
117 fp_term = dc->writeback_rate_fp_term_high *
118 (c->gc_stats.in_use - BCH_WRITEBACK_FRAGMENT_THRESHOLD_HIGH);
119 }
> 120 fps = (dirty / dirty_buckets) * fp_term;
121 if (fragment > 3 && fps > proportional_scaled) {
122 //Only overrite the p when fragment > 3
123 proportional_scaled = fps;
124 }
125 }
126
127 if ((error < 0 && dc->writeback_rate_integral > 0) ||
128 (error > 0 && time_before64(local_clock(),
129 dc->writeback_rate.next + NSEC_PER_MSEC))) {
130 /*
131 * Only decrease the integral term if it's more than
132 * zero. Only increase the integral term if the device
133 * is keeping up. (Don't wind up the integral
134 * ineffectively in either case).
135 *
136 * It's necessary to scale this by
137 * writeback_rate_update_seconds to keep the integral
138 * term dimensioned properly.
139 */
140 dc->writeback_rate_integral += error *
141 dc->writeback_rate_update_seconds;
142 }
143
144 integral_scaled = div_s64(dc->writeback_rate_integral,
145 dc->writeback_rate_i_term_inverse);
146
147 new_rate = clamp_t(int32_t, (proportional_scaled + integral_scaled),
148 dc->writeback_rate_minimum, NSEC_PER_SEC);
149
150 dc->writeback_rate_proportional = proportional_scaled;
151 dc->writeback_rate_integral_scaled = integral_scaled;
152 dc->writeback_rate_change = new_rate -
153 atomic_long_read(&dc->writeback_rate.rate);
154 atomic_long_set(&dc->writeback_rate.rate, new_rate);
155 dc->writeback_rate_target = target;
156 }
157
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
Download attachment ".config.gz" of type "application/gzip" (30207 bytes)
Powered by blists - more mailing lists