public inbox for [email protected]
 help / color / mirror / Atom feed
From: kernel test robot <[email protected]>
To: Rick Yiu <[email protected]>
Cc: [email protected], [email protected],
	GNU/Weeb Mailing List <[email protected]>,
	[email protected]
Subject: [ammarfaizi2-block:google/android/kernel/common/android13-5.10 9999/9999] kernel/sched/pelt.c:220:5: warning: no previous prototype for function '___update_load_sum'
Date: Tue, 29 Mar 2022 14:22:07 +0800	[thread overview]
Message-ID: <[email protected]> (raw)

tree:   https://github.com/ammarfaizi2/linux-block google/android/kernel/common/android13-5.10
head:   e3356ca0a6c24e1ccdde6e9f80875701218ab090
commit: e3356ca0a6c24e1ccdde6e9f80875701218ab090 [9999/9999] ANDROID: sched: Add vendor hook for util-update related functions
config: arm64-randconfig-r032-20220327 (https://download.01.org/0day-ci/archive/20220329/[email protected]/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 0f6d9501cf49ce02937099350d08f20c4af86f3d)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm64 cross compiling tool for clang build
        # apt-get install binutils-aarch64-linux-gnu
        # https://github.com/ammarfaizi2/linux-block/commit/e3356ca0a6c24e1ccdde6e9f80875701218ab090
        git remote add ammarfaizi2-block https://github.com/ammarfaizi2/linux-block
        git fetch --no-tags ammarfaizi2-block google/android/kernel/common/android13-5.10
        git checkout e3356ca0a6c24e1ccdde6e9f80875701218ab090
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm64 SHELL=/bin/bash kernel/sched/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <[email protected]>

All warnings (new ones prefixed by >>):

>> kernel/sched/pelt.c:220:5: warning: no previous prototype for function '___update_load_sum' [-Wmissing-prototypes]
   int ___update_load_sum(u64 now, struct sched_avg *sa,
       ^
   kernel/sched/pelt.c:220:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   int ___update_load_sum(u64 now, struct sched_avg *sa,
   ^
   static 
>> kernel/sched/pelt.c:297:6: warning: no previous prototype for function '___update_load_avg' [-Wmissing-prototypes]
   void ___update_load_avg(struct sched_avg *sa, unsigned long load)
        ^
   kernel/sched/pelt.c:297:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void ___update_load_avg(struct sched_avg *sa, unsigned long load)
   ^
   static 
   2 warnings generated.


vim +/___update_load_sum +220 kernel/sched/pelt.c

   191	
   192	/*
   193	 * We can represent the historical contribution to runnable average as the
   194	 * coefficients of a geometric series.  To do this we sub-divide our runnable
   195	 * history into segments of approximately 1ms (1024us); label the segment that
   196	 * occurred N-ms ago p_N, with p_0 corresponding to the current period, e.g.
   197	 *
   198	 * [<- 1024us ->|<- 1024us ->|<- 1024us ->| ...
   199	 *      p0            p1           p2
   200	 *     (now)       (~1ms ago)  (~2ms ago)
   201	 *
   202	 * Let u_i denote the fraction of p_i that the entity was runnable.
   203	 *
   204	 * We then designate the fractions u_i as our co-efficients, yielding the
   205	 * following representation of historical load:
   206	 *   u_0 + u_1*y + u_2*y^2 + u_3*y^3 + ...
   207	 *
   208	 * We choose y based on the with of a reasonably scheduling period, fixing:
   209	 *   y^32 = 0.5
   210	 *
   211	 * This means that the contribution to load ~32ms ago (u_32) will be weighted
   212	 * approximately half as much as the contribution to load within the last ms
   213	 * (u_0).
   214	 *
   215	 * When a period "rolls over" and we have new u_0`, multiplying the previous
   216	 * sum again by y is sufficient to update:
   217	 *   load_avg = u_0` + y*(u_0 + u_1*y + u_2*y^2 + ... )
   218	 *            = u_0 + u_1*y + u_2*y^2 + ... [re-labeling u_i --> u_{i+1}]
   219	 */
 > 220	int ___update_load_sum(u64 now, struct sched_avg *sa,
   221			       unsigned long load, unsigned long runnable, int running)
   222	{
   223		u64 delta;
   224	
   225		delta = now - sa->last_update_time;
   226		/*
   227		 * This should only happen when time goes backwards, which it
   228		 * unfortunately does during sched clock init when we swap over to TSC.
   229		 */
   230		if ((s64)delta < 0) {
   231			sa->last_update_time = now;
   232			return 0;
   233		}
   234	
   235		/*
   236		 * Use 1024ns as the unit of measurement since it's a reasonable
   237		 * approximation of 1us and fast to compute.
   238		 */
   239		delta >>= 10;
   240		if (!delta)
   241			return 0;
   242	
   243		sa->last_update_time += delta << 10;
   244	
   245		/*
   246		 * running is a subset of runnable (weight) so running can't be set if
   247		 * runnable is clear. But there are some corner cases where the current
   248		 * se has been already dequeued but cfs_rq->curr still points to it.
   249		 * This means that weight will be 0 but not running for a sched_entity
   250		 * but also for a cfs_rq if the latter becomes idle. As an example,
   251		 * this happens during idle_balance() which calls
   252		 * update_blocked_averages().
   253		 *
   254		 * Also see the comment in accumulate_sum().
   255		 */
   256		if (!load)
   257			runnable = running = 0;
   258	
   259		/*
   260		 * Now we know we crossed measurement unit boundaries. The *_avg
   261		 * accrues by two steps:
   262		 *
   263		 * Step 1: accumulate *_sum since last_update_time. If we haven't
   264		 * crossed period boundaries, finish.
   265		 */
   266		if (!accumulate_sum(delta, sa, load, runnable, running))
   267			return 0;
   268	
   269		return 1;
   270	}
   271	EXPORT_SYMBOL_GPL(___update_load_sum);
   272	
   273	/*
   274	 * When syncing *_avg with *_sum, we must take into account the current
   275	 * position in the PELT segment otherwise the remaining part of the segment
   276	 * will be considered as idle time whereas it's not yet elapsed and this will
   277	 * generate unwanted oscillation in the range [1002..1024[.
   278	 *
   279	 * The max value of *_sum varies with the position in the time segment and is
   280	 * equals to :
   281	 *
   282	 *   LOAD_AVG_MAX*y + sa->period_contrib
   283	 *
   284	 * which can be simplified into:
   285	 *
   286	 *   LOAD_AVG_MAX - 1024 + sa->period_contrib
   287	 *
   288	 * because LOAD_AVG_MAX*y == LOAD_AVG_MAX-1024
   289	 *
   290	 * The same care must be taken when a sched entity is added, updated or
   291	 * removed from a cfs_rq and we need to update sched_avg. Scheduler entities
   292	 * and the cfs rq, to which they are attached, have the same position in the
   293	 * time segment because they use the same clock. This means that we can use
   294	 * the period_contrib of cfs_rq when updating the sched_avg of a sched_entity
   295	 * if it's more convenient.
   296	 */
 > 297	void ___update_load_avg(struct sched_avg *sa, unsigned long load)
   298	{
   299		u32 divider = get_pelt_divider(sa);
   300	
   301		/*
   302		 * Step 2: update *_avg.
   303		 */
   304		sa->load_avg = div_u64(load * sa->load_sum, divider);
   305		sa->runnable_avg = div_u64(sa->runnable_sum, divider);
   306		WRITE_ONCE(sa->util_avg, sa->util_sum / divider);
   307	}
   308	EXPORT_SYMBOL_GPL(___update_load_avg);
   309	

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

                 reply	other threads:[~2022-03-29  6:23 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox