linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
@ 2015-10-02 17:29 Waiman Long
  2015-10-02 18:04 ` kbuild test robot
                   ` (4 more replies)
  0 siblings, 5 replies; 18+ messages in thread
From: Waiman Long @ 2015-10-02 17:29 UTC (permalink / raw)
  To: Dave Chinner, Tejun Heo, Christoph Lameter
  Cc: linux-kernel, xfs, Scott J Norton, Douglas Hatch, Waiman Long

In __percpu_counter_compare(), if the current imprecise count is
within (batch*nr_cpus) of the input value to be compared, a call
to percpu_counter_sum() will be made to get the precise count. The
percpu_counter_sum() call, however, can be expensive especially on
large systems where there are a lot of CPUs. Large systems also make
it more likely that percpu_counter_sum() will be called.

The xfs_mod_fdblocks() function calls __percpu_counter_compare()
twice. First to see if a smaller batch size should be used for
__percpu_counter_add() and the second call to compare the actual
size needed. This can potentially lead to 2 calls to the expensive
percpu_counter_sum() function.

This patch added an extra argument to __percpu_counter_compare()
to return the precise count, if computed. The caller will need to
initialize it to an invalid value that it can tell if the precise
count is being returned.

The xfs_mod_fdblocks() function was then modified to use the
precise count for comparison, if returned. Otherwise, it will call
__percpu_counter_compare() the second time.

Running the AIM7 disk workload with XFS filesystem, the jobs/min
on a 40-core 80-thread 4-socket Haswell-EX system increases from
3805k to 4276k (12% increase) with this patch applied. As measured
by the perf tool, the %CPU cycle consumed by __percpu_counter_sum()
decreases from 12.64% to 7.08%.

Signed-off-by: Waiman Long <Waiman.Long@hpe.com>
---
 fs/xfs/xfs_mount.c             |   17 +++++++++++++----
 include/linux/percpu_counter.h |    9 +++++----
 lib/percpu_counter.c           |   11 ++++++++++-
 3 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index bf92e0c..8586b62 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -1115,7 +1115,7 @@ xfs_mod_icount(
 	int64_t			delta)
 {
 	__percpu_counter_add(&mp->m_icount, delta, XFS_ICOUNT_BATCH);
-	if (__percpu_counter_compare(&mp->m_icount, 0, XFS_ICOUNT_BATCH) < 0) {
+	if (__percpu_counter_compare(&mp->m_icount, 0, XFS_ICOUNT_BATCH, NULL) < 0) {
 		ASSERT(0);
 		percpu_counter_add(&mp->m_icount, -delta);
 		return -EINVAL;
@@ -1154,6 +1154,7 @@ xfs_mod_fdblocks(
 	int64_t			lcounter;
 	long long		res_used;
 	s32			batch;
+	s64			pcount;	/* Precise count */
 
 	if (delta > 0) {
 		/*
@@ -1187,15 +1188,23 @@ xfs_mod_fdblocks(
 	 * then make everything serialise as we are real close to
 	 * ENOSPC.
 	 */
+	pcount = -1;
 	if (__percpu_counter_compare(&mp->m_fdblocks, 2 * XFS_FDBLOCKS_BATCH,
-				     XFS_FDBLOCKS_BATCH) < 0)
+				     XFS_FDBLOCKS_BATCH, &pcount) < 0)
 		batch = 1;
 	else
 		batch = XFS_FDBLOCKS_BATCH;
 
 	__percpu_counter_add(&mp->m_fdblocks, delta, batch);
-	if (__percpu_counter_compare(&mp->m_fdblocks, XFS_ALLOC_SET_ASIDE(mp),
-				     XFS_FDBLOCKS_BATCH) >= 0) {
+	if (pcount >= 0) {
+		/*
+		 * No need to call __percpu_counter_compare() again if the
+		 * precise count has been computed.
+		 */
+		if (pcount + delta >= XFS_ALLOC_SET_ASIDE(mp))
+			return 0;	/* we have space */
+	} else if (__percpu_counter_compare(&mp->m_fdblocks,
+		   XFS_ALLOC_SET_ASIDE(mp), XFS_FDBLOCKS_BATCH, NULL) >= 0) {
 		/* we had space! */
 		return 0;
 	}
diff --git a/include/linux/percpu_counter.h b/include/linux/percpu_counter.h
index 84a1094..4690143 100644
--- a/include/linux/percpu_counter.h
+++ b/include/linux/percpu_counter.h
@@ -41,11 +41,12 @@ void percpu_counter_destroy(struct percpu_counter *fbc);
 void percpu_counter_set(struct percpu_counter *fbc, s64 amount);
 void __percpu_counter_add(struct percpu_counter *fbc, s64 amount, s32 batch);
 s64 __percpu_counter_sum(struct percpu_counter *fbc);
-int __percpu_counter_compare(struct percpu_counter *fbc, s64 rhs, s32 batch);
+int __percpu_counter_compare(struct percpu_counter *fbc, s64 rhs, s32 batch,
+			     s64 *pcnt);
 
 static inline int percpu_counter_compare(struct percpu_counter *fbc, s64 rhs)
 {
-	return __percpu_counter_compare(fbc, rhs, percpu_counter_batch);
+	return __percpu_counter_compare(fbc, rhs, percpu_counter_batch, NULL);
 }
 
 static inline void percpu_counter_add(struct percpu_counter *fbc, s64 amount)
@@ -121,8 +122,8 @@ static inline int percpu_counter_compare(struct percpu_counter *fbc, s64 rhs)
 		return 0;
 }
 
-static inline int
-__percpu_counter_compare(struct percpu_counter *fbc, s64 rhs, s32 batch)
+static inline int __percpu_counter_compare(struct percpu_counter *fbc, s64 rhs,
+					   s32 batch, s64 *pcnt))
 {
 	return percpu_counter_compare(fbc, rhs);
 }
diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
index f051d69..37e253c 100644
--- a/lib/percpu_counter.c
+++ b/lib/percpu_counter.c
@@ -196,8 +196,14 @@ static int percpu_counter_hotcpu_callback(struct notifier_block *nb,
 /*
  * Compare counter against given value.
  * Return 1 if greater, 0 if equal and -1 if less
+ *
+ * The precise count, if computed, will be returned in the location pointed
+ * to by pcnt. The *pcnt value should be properly initialized before calling
+ * this function so that the caller can easily distinguish if the count has
+ * been returned.
  */
-int __percpu_counter_compare(struct percpu_counter *fbc, s64 rhs, s32 batch)
+int __percpu_counter_compare(struct percpu_counter *fbc, s64 rhs, s32 batch,
+			     s64 *pcnt)
 {
 	s64	count;
 
@@ -211,6 +217,9 @@ int __percpu_counter_compare(struct percpu_counter *fbc, s64 rhs, s32 batch)
 	}
 	/* Need to use precise count */
 	count = percpu_counter_sum(fbc);
+
+	if (pcnt)
+		*pcnt = count;	/* Store the precise count */
 	if (count > rhs)
 		return 1;
 	else if (count < rhs)
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-02 17:29 [PATCH] percpu_counter: return precise count from __percpu_counter_compare() Waiman Long
@ 2015-10-02 18:04 ` kbuild test robot
  2015-10-05 23:03   ` Waiman Long
  2015-10-02 18:05 ` kbuild test robot
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 18+ messages in thread
From: kbuild test robot @ 2015-10-02 18:04 UTC (permalink / raw)
  To: Waiman Long
  Cc: kbuild-all, Dave Chinner, Tejun Heo, Christoph Lameter,
	linux-kernel, xfs, Scott J Norton, Douglas Hatch, Waiman Long

[-- Attachment #1: Type: text/plain, Size: 16504 bytes --]

Hi Waiman,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore]

config: ia64-allnoconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=ia64 

All error/warnings (new ones prefixed by >>):

   include/linux/sched.h:326:19: error: storage class specified for parameter 'mmlist_lock'
    extern spinlock_t mmlist_lock;
                      ^
   include/linux/sched.h:328:1: warning: empty declaration
    struct task_struct;
    ^
   include/linux/sched.h:334:13: error: storage class specified for parameter 'sched_init'
    extern void sched_init(void);
                ^
   include/linux/sched.h:335:13: error: storage class specified for parameter 'sched_init_smp'
    extern void sched_init_smp(void);
                ^
   include/linux/sched.h:336:24: error: storage class specified for parameter 'schedule_tail'
    extern asmlinkage void schedule_tail(struct task_struct *prev);
                           ^
   include/linux/sched.h:337:13: error: storage class specified for parameter 'init_idle'
    extern void init_idle(struct task_struct *idle, int cpu);
                ^
   include/linux/sched.h:338:13: error: storage class specified for parameter 'init_idle_bootup_task'
    extern void init_idle_bootup_task(struct task_struct *idle);
                ^
   include/linux/sched.h:340:22: error: storage class specified for parameter 'cpu_isolated_map'
    extern cpumask_var_t cpu_isolated_map;
                         ^
   include/linux/sched.h:342:12: error: storage class specified for parameter 'runqueue_is_locked'
    extern int runqueue_is_locked(int cpu);
               ^
   include/linux/sched.h:349:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline void nohz_balance_enter_idle(int cpu) { }
                                                        ^
   include/linux/sched.h:350:48: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline void set_cpu_sd_state_idle(void) { }
                                                   ^
   include/linux/sched.h:356:13: error: storage class specified for parameter 'show_state_filter'
    extern void show_state_filter(unsigned long state_filter);
                ^
   include/linux/sched.h:359:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:363:13: error: storage class specified for parameter 'show_regs'
    extern void show_regs(struct pt_regs *);
                ^
   include/linux/sched.h:370:13: error: storage class specified for parameter 'show_stack'
    extern void show_stack(struct task_struct *task, unsigned long *sp);
                ^
   include/linux/sched.h:372:13: error: storage class specified for parameter 'cpu_init'
    extern void cpu_init (void);
                ^
   include/linux/sched.h:373:13: error: storage class specified for parameter 'trap_init'
    extern void trap_init(void);
                ^
   include/linux/sched.h:374:13: error: storage class specified for parameter 'update_process_times'
    extern void update_process_times(int user);
                ^
   include/linux/sched.h:375:13: error: storage class specified for parameter 'scheduler_tick'
    extern void scheduler_tick(void);
                ^
   include/linux/sched.h:377:13: error: storage class specified for parameter 'sched_show_task'
    extern void sched_show_task(struct task_struct *p);
                ^
   include/linux/sched.h:390:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:393:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:396:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:399:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:407:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:415:13: error: storage class specified for parameter '__sched_text_start'
    extern char __sched_text_start[], __sched_text_end[];
                ^
   include/linux/sched.h:415:35: error: storage class specified for parameter '__sched_text_end'
    extern char __sched_text_start[], __sched_text_end[];
                                      ^
   include/linux/sched.h:418:12: error: storage class specified for parameter 'in_sched_functions'
    extern int in_sched_functions(unsigned long addr);
               ^
   include/linux/sched.h:421:20: error: storage class specified for parameter 'schedule_timeout'
    extern signed long schedule_timeout(signed long timeout);
                       ^
   include/linux/sched.h:422:20: error: storage class specified for parameter 'schedule_timeout_interruptible'
    extern signed long schedule_timeout_interruptible(signed long timeout);
                       ^
   include/linux/sched.h:423:20: error: storage class specified for parameter 'schedule_timeout_killable'
    extern signed long schedule_timeout_killable(signed long timeout);
                       ^
   include/linux/sched.h:424:20: error: storage class specified for parameter 'schedule_timeout_uninterruptible'
    extern signed long schedule_timeout_uninterruptible(signed long timeout);
                       ^
   In file included from include/linux/linkage.h:7:0,
                    from include/linux/kernel.h:6,
                    from include/linux/sched.h:17,
                    from arch/ia64/kernel/asm-offsets.c:9:
>> arch/ia64/include/asm/linkage.h:6:35: error: expected declaration specifiers before '__attribute__'
    #define asmlinkage CPP_ASMLINKAGE __attribute__((syscall_linkage))
                                      ^
>> include/linux/sched.h:425:1: note: in expansion of macro 'asmlinkage'
    asmlinkage void schedule(void);
    ^
   In file included from arch/ia64/kernel/asm-offsets.c:9:0:
   include/linux/sched.h:426:13: error: storage class specified for parameter 'schedule_preempt_disabled'
    extern void schedule_preempt_disabled(void);
                ^
   include/linux/sched.h:428:13: error: storage class specified for parameter 'io_schedule_timeout'
    extern long io_schedule_timeout(long timeout);
                ^
   include/linux/sched.h:431:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:435:1: warning: empty declaration
    struct nsproxy;
    ^
   include/linux/sched.h:436:1: warning: empty declaration
    struct user_namespace;
    ^
   include/linux/sched.h:439:13: error: storage class specified for parameter 'arch_pick_mmap_layout'
    extern void arch_pick_mmap_layout(struct mm_struct *mm);
                ^
   include/linux/sched.h:441:1: error: storage class specified for parameter 'arch_get_unmapped_area'
    arch_get_unmapped_area(struct file *, unsigned long, unsigned long,
    ^
   include/linux/sched.h:444:1: error: storage class specified for parameter 'arch_get_unmapped_area_topdown'
    arch_get_unmapped_area_topdown(struct file *filp, unsigned long addr,
    ^
   include/linux/sched.h:461:13: error: storage class specified for parameter 'set_dumpable'
    extern void set_dumpable(struct mm_struct *mm, int value);
                ^
   include/linux/sched.h:469:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:474:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:510:1: warning: empty declaration
    struct sighand_struct {
    ^
   include/linux/sched.h:517:1: warning: empty declaration
    struct pacct_struct {
    ^
   include/linux/sched.h:525:1: warning: empty declaration
    struct cpu_itimer {
    ^
   include/linux/sched.h:541:1: warning: empty declaration
    struct prev_cputime {
    ^
   include/linux/sched.h:550:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:567:1: warning: empty declaration
    struct task_cputime {
    ^
   include/linux/sched.h:589:1: warning: empty declaration
    struct task_cputime_atomic {
    ^
   include/linux/sched.h:626:1: warning: empty declaration
    struct thread_group_cputimer {
    ^
   include/linux/sched.h:632:1: warning: empty declaration
    struct autogroup;
    ^
   include/linux/sched.h:641:1: warning: empty declaration
    struct signal_struct {
    ^
   include/linux/sched.h:806:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:814:1: warning: empty declaration
    struct user_struct {
    ^
   include/linux/sched.h:848:12: error: storage class specified for parameter 'uids_sysfs_init'
    extern int uids_sysfs_init(void);
               ^
   include/linux/sched.h:850:28: error: storage class specified for parameter 'find_user'
    extern struct user_struct *find_user(kuid_t);
                               ^
   include/linux/sched.h:852:27: error: storage class specified for parameter 'root_user'
    extern struct user_struct root_user;
                              ^
   include/linux/sched.h:856:1: warning: empty declaration
    struct backing_dev_info;
    ^
   include/linux/sched.h:857:1: warning: empty declaration
    struct reclaim_state;
    ^
   include/linux/sched.h:906:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:917:1: warning: empty declaration
    enum cpu_idle_type {
    ^
   include/linux/sched.h:956:1: warning: empty declaration
    struct wake_q_node {
    ^
   include/linux/sched.h:960:1: warning: empty declaration
    struct wake_q_head {
    ^
   include/linux/sched.h:970:13: error: storage class specified for parameter 'wake_q_add'
    extern void wake_q_add(struct wake_q_head *head,
                ^
   include/linux/sched.h:972:13: error: storage class specified for parameter 'wake_up_q'
    extern void wake_up_q(struct wake_q_head *head);
                ^
   include/linux/sched.h:1155:1: warning: empty declaration
    struct sched_domain_attr;
    ^
   include/linux/sched.h:1160:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1164:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1171:1: warning: empty declaration
    struct io_context;   /* See blkdev.h */
    ^
>> include/linux/sched.h:1175:13: error: storage class specified for parameter 'prefetch_stack'
    extern void prefetch_stack(struct task_struct *t);
                ^
   include/linux/sched.h:1180:1: warning: empty declaration
    struct audit_context;  /* See audit.c */
    ^
   include/linux/sched.h:1181:1: warning: empty declaration
    struct mempolicy;
    ^
   include/linux/sched.h:1182:1: warning: empty declaration
    struct pipe_inode_info;
    ^
   include/linux/sched.h:1183:1: warning: empty declaration
    struct uts_namespace;
    ^
   include/linux/sched.h:1185:1: warning: empty declaration
    struct load_weight {
    ^
   include/linux/sched.h:1204:1: warning: empty declaration
    struct sched_avg {
    ^
   include/linux/sched.h:1246:1: warning: empty declaration
    struct sched_entity {
    ^
   include/linux/sched.h:1278:1: warning: empty declaration
    struct sched_rt_entity {
    ^
   include/linux/sched.h:1294:1: warning: empty declaration
    struct sched_dl_entity {
    ^
   include/linux/sched.h:1343:1: warning: empty declaration
    union rcu_special {
    ^
   include/linux/sched.h:1350:1: warning: empty declaration
    struct rcu_node;
    ^
   include/linux/sched.h:1352:1: warning: empty declaration
    enum perf_event_task_context {
    ^
   include/linux/sched.h:1360:1: warning: empty declaration
    struct tlbflush_unmap_batch {
    ^
   include/linux/sched.h:1378:1: warning: empty declaration
    struct task_struct {
    ^
   include/linux/sched.h:1850:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1853:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1857:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1860:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1864:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1870:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1875:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1885:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1890:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1894:1: warning: empty declaration
    struct pid_namespace;
    ^
   include/linux/sched.h:1913:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1919:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1924:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1930:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1937:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/sched.h:1942:19: error: storage class specified for parameter 'pid_alive'
    static inline int pid_alive(const struct task_struct *p);
                      ^
   include/linux/sched.h:1942:19: warning: parameter 'pid_alive' declared 'inline'
   include/linux/sched.h:1942:42: warning: 'always_inline' attribute ignored [-Wattributes]
    static inline int pid_alive(const struct task_struct *p);
                                             ^
   include/linux/sched.h:1942:19: error: 'no_instrument_function' attribute applies only to functions
    static inline int pid_alive(const struct task_struct *p);
                      ^
   include/linux/sched.h:1944:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
..

vim +/__attribute__ +6 arch/ia64/include/asm/linkage.h

^1da177e include/asm-ia64/linkage.h      Linus Torvalds 2005-04-16   1  #ifndef __ASM_LINKAGE_H
^1da177e include/asm-ia64/linkage.h      Linus Torvalds 2005-04-16   2  #define __ASM_LINKAGE_H
^1da177e include/asm-ia64/linkage.h      Linus Torvalds 2005-04-16   3  
ab7efcc9 include/asm-ia64/linkage.h      Jan Beulich    2006-03-24   4  #ifndef __ASSEMBLY__
ab7efcc9 include/asm-ia64/linkage.h      Jan Beulich    2006-03-24   5  
^1da177e include/asm-ia64/linkage.h      Linus Torvalds 2005-04-16  @6  #define asmlinkage CPP_ASMLINKAGE __attribute__((syscall_linkage))
^1da177e include/asm-ia64/linkage.h      Linus Torvalds 2005-04-16   7  
ab7efcc9 include/asm-ia64/linkage.h      Jan Beulich    2006-03-24   8  #else
ab7efcc9 include/asm-ia64/linkage.h      Jan Beulich    2006-03-24   9  
ab7efcc9 include/asm-ia64/linkage.h      Jan Beulich    2006-03-24  10  #include <asm/asmmacro.h>
ab7efcc9 include/asm-ia64/linkage.h      Jan Beulich    2006-03-24  11  
ab7efcc9 include/asm-ia64/linkage.h      Jan Beulich    2006-03-24  12  #endif
ab7efcc9 include/asm-ia64/linkage.h      Jan Beulich    2006-03-24  13  
e1b5bb6d arch/ia64/include/asm/linkage.h Al Viro        2013-01-21  14  #define cond_syscall(x) asm(".weak\t" #x "#\n" #x "#\t=\tsys_ni_syscall#")

:::::: The code at line 6 was first introduced by commit
:::::: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:::::: TO: Linus Torvalds <torvalds@ppc970.osdl.org>
:::::: CC: Linus Torvalds <torvalds@ppc970.osdl.org>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 5391 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-02 17:29 [PATCH] percpu_counter: return precise count from __percpu_counter_compare() Waiman Long
  2015-10-02 18:04 ` kbuild test robot
@ 2015-10-02 18:05 ` kbuild test robot
  2015-10-02 18:12 ` kbuild test robot
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 18+ messages in thread
From: kbuild test robot @ 2015-10-02 18:05 UTC (permalink / raw)
  To: Waiman Long
  Cc: kbuild-all, Dave Chinner, Tejun Heo, Christoph Lameter,
	linux-kernel, xfs, Scott J Norton, Douglas Hatch, Waiman Long

[-- Attachment #1: Type: text/plain, Size: 12503 bytes --]

Hi Waiman,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore]

config: i386-alldefconfig (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/proportions.h:12:0,
                    from include/linux/sched.h:43,
                    from include/linux/uaccess.h:4,
                    from include/linux/crypto.h:26,
                    from arch/x86/kernel/asm-offsets.c:8:
   include/linux/percpu_counter.h: In function '__percpu_counter_compare':
   include/linux/percpu_counter.h:126:30: error: expected declaration specifiers before ')' token
            s32 batch, s64 *pcnt))
                                 ^
   include/linux/percpu_counter.h:133:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/percpu_counter.h:141:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/percpu_counter.h:146:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/percpu_counter.h:155:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/percpu_counter.h:160:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/percpu_counter.h:165:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/percpu_counter.h:170:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/percpu_counter.h:177:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/percpu_counter.h:182:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/percpu_counter.h:187:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   In file included from include/linux/sched.h:43:0,
                    from include/linux/uaccess.h:4,
                    from include/linux/crypto.h:26,
                    from arch/x86/kernel/asm-offsets.c:8:
   include/linux/proportions.h:17:1: warning: empty declaration
    struct prop_global {
    ^
   include/linux/proportions.h:38:1: warning: empty declaration
    struct prop_descriptor {
    ^
   include/linux/proportions.h:51:1: warning: empty declaration
    struct prop_local_percpu {
    ^
   include/linux/proportions.h:73:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/proportions.h:102:1: warning: empty declaration
    struct prop_local_single {
    ^
   include/linux/proportions.h:129:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   In file included from include/linux/seccomp.h:4:0,
                    from include/linux/sched.h:44,
                    from include/linux/uaccess.h:4,
                    from include/linux/crypto.h:26,
                    from arch/x86/kernel/asm-offsets.c:8:
   include/uapi/linux/seccomp.h:47:1: warning: empty declaration
    struct seccomp_data {
    ^
   In file included from include/linux/sched.h:44:0,
                    from include/linux/uaccess.h:4,
                    from include/linux/crypto.h:26,
                    from arch/x86/kernel/asm-offsets.c:8:
   include/linux/seccomp.h:13:1: warning: empty declaration
    struct seccomp_filter;
    ^
   include/linux/seccomp.h:25:1: warning: empty declaration
    struct seccomp {
    ^
>> include/linux/seccomp.h:31:12: error: storage class specified for parameter '__secure_computing'
    extern int __secure_computing(void);
               ^
   include/linux/seccomp.h:33:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
>> include/linux/seccomp.h:42:12: error: storage class specified for parameter 'seccomp_phase1'
    extern u32 seccomp_phase1(struct seccomp_data *sd);
               ^
>> include/linux/seccomp.h:48:13: error: storage class specified for parameter 'prctl_get_seccomp'
    extern long prctl_get_seccomp(void);
                ^
>> include/linux/seccomp.h:49:13: error: storage class specified for parameter 'prctl_set_seccomp'
    extern long prctl_set_seccomp(unsigned long, char __user *);
                ^
   include/linux/seccomp.h:52:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/seccomp.h:90:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/seccomp.h:94:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   In file included from include/linux/sched.h:46:0,
                    from include/linux/uaccess.h:4,
                    from include/linux/crypto.h:26,
                    from arch/x86/kernel/asm-offsets.c:8:
   include/linux/rculist.h:31:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/rculist.h:51:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/rculist.h:79:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/rculist.h:101:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/rculist.h:130:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/rculist.h:156:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/rculist.h:173:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/rculist.h:201:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/rculist.h:344:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/rculist.h:358:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/rculist.h:397:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/rculist.h:427:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/rculist.h:454:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   In file included from include/linux/sched.h:47:0,
                    from include/linux/uaccess.h:4,
                    from include/linux/crypto.h:26,
                    from arch/x86/kernel/asm-offsets.c:8:
   include/linux/rtmutex.h:19:12: error: storage class specified for parameter 'max_lock_depth'
    extern int max_lock_depth; /* for sysctl */
               ^
   include/linux/rtmutex.h:29:1: warning: empty declaration
    struct rt_mutex {
    ^
   include/linux/rtmutex.h:42:1: warning: empty declaration
    struct rt_mutex_waiter;
    ^
   include/linux/rtmutex.h:43:1: warning: empty declaration
    struct hrtimer_sleeper;
    ^
   include/linux/rtmutex.h:52:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
     {
     ^
   include/linux/rtmutex.h:85:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/rtmutex.h:89:13: error: storage class specified for parameter '__rt_mutex_init'
    extern void __rt_mutex_init(struct rt_mutex *lock, const char *name);
                ^
   include/linux/rtmutex.h:90:13: error: storage class specified for parameter 'rt_mutex_destroy'
    extern void rt_mutex_destroy(struct rt_mutex *lock);
                ^
   include/linux/rtmutex.h:92:13: error: storage class specified for parameter 'rt_mutex_lock'
    extern void rt_mutex_lock(struct rt_mutex *lock);
                ^
   include/linux/rtmutex.h:93:12: error: storage class specified for parameter 'rt_mutex_lock_interruptible'
    extern int rt_mutex_lock_interruptible(struct rt_mutex *lock);
               ^
   include/linux/rtmutex.h:94:12: error: storage class specified for parameter 'rt_mutex_timed_lock'
    extern int rt_mutex_timed_lock(struct rt_mutex *lock,
               ^
   include/linux/rtmutex.h:97:12: error: storage class specified for parameter 'rt_mutex_trylock'
    extern int rt_mutex_trylock(struct rt_mutex *lock);
               ^
   include/linux/rtmutex.h:99:13: error: storage class specified for parameter 'rt_mutex_unlock'
    extern void rt_mutex_unlock(struct rt_mutex *lock);
                ^
   In file included from include/linux/resource.h:4:0,
                    from include/linux/sched.h:51,
                    from include/linux/uaccess.h:4,

vim +/__secure_computing +31 include/linux/seccomp.h

c2e1f2e30 Kees Cook        2014-06-05   7  
^1da177e4 Linus Torvalds   2005-04-16   8  #ifdef CONFIG_SECCOMP
^1da177e4 Linus Torvalds   2005-04-16   9  
^1da177e4 Linus Torvalds   2005-04-16  10  #include <linux/thread_info.h>
^1da177e4 Linus Torvalds   2005-04-16  11  #include <asm/seccomp.h>
^1da177e4 Linus Torvalds   2005-04-16  12  
e2cfabdfd Will Drewry      2012-04-12 @13  struct seccomp_filter;
e2cfabdfd Will Drewry      2012-04-12  14  /**
e2cfabdfd Will Drewry      2012-04-12  15   * struct seccomp - the state of a seccomp'ed process
e2cfabdfd Will Drewry      2012-04-12  16   *
e2cfabdfd Will Drewry      2012-04-12  17   * @mode:  indicates one of the valid values above for controlled
e2cfabdfd Will Drewry      2012-04-12  18   *         system calls available to a process.
dbd952127 Kees Cook        2014-06-27  19   * @filter: must always point to a valid seccomp-filter or NULL as it is
dbd952127 Kees Cook        2014-06-27  20   *          accessed without locking during system call entry.
e2cfabdfd Will Drewry      2012-04-12  21   *
e2cfabdfd Will Drewry      2012-04-12  22   *          @filter must only be accessed from the context of current as there
dbd952127 Kees Cook        2014-06-27  23   *          is no read locking.
e2cfabdfd Will Drewry      2012-04-12  24   */
932ecebb0 Will Drewry      2012-04-12 @25  struct seccomp {
932ecebb0 Will Drewry      2012-04-12  26  	int mode;
e2cfabdfd Will Drewry      2012-04-12  27  	struct seccomp_filter *filter;
932ecebb0 Will Drewry      2012-04-12  28  };
^1da177e4 Linus Torvalds   2005-04-16  29  
a4412fc94 Andy Lutomirski  2014-07-21  30  #ifdef CONFIG_HAVE_ARCH_SECCOMP_FILTER
a4412fc94 Andy Lutomirski  2014-07-21 @31  extern int __secure_computing(void);
a4412fc94 Andy Lutomirski  2014-07-21  32  static inline int secure_computing(void)
^1da177e4 Linus Torvalds   2005-04-16 @33  {
^1da177e4 Linus Torvalds   2005-04-16  34  	if (unlikely(test_thread_flag(TIF_SECCOMP)))
a4412fc94 Andy Lutomirski  2014-07-21  35  		return  __secure_computing();
acf3b2c71 Will Drewry      2012-04-12  36  	return 0;
^1da177e4 Linus Torvalds   2005-04-16  37  }
13aa72f0f Andy Lutomirski  2014-07-21  38  
13aa72f0f Andy Lutomirski  2014-07-21  39  #define SECCOMP_PHASE1_OK	0
13aa72f0f Andy Lutomirski  2014-07-21  40  #define SECCOMP_PHASE1_SKIP	1
13aa72f0f Andy Lutomirski  2014-07-21  41  
d39bd00de Andy Lutomirski  2014-07-21 @42  extern u32 seccomp_phase1(struct seccomp_data *sd);
13aa72f0f Andy Lutomirski  2014-07-21  43  int seccomp_phase2(u32 phase1_result);
a4412fc94 Andy Lutomirski  2014-07-21  44  #else
a4412fc94 Andy Lutomirski  2014-07-21  45  extern void secure_computing_strict(int this_syscall);
a4412fc94 Andy Lutomirski  2014-07-21  46  #endif
e4da89d02 Will Drewry      2012-04-17  47  
1d9d02fee Andrea Arcangeli 2007-07-15 @48  extern long prctl_get_seccomp(void);
e2cfabdfd Will Drewry      2012-04-12 @49  extern long prctl_set_seccomp(unsigned long, char __user *);
1d9d02fee Andrea Arcangeli 2007-07-15  50  
932ecebb0 Will Drewry      2012-04-12  51  static inline int seccomp_mode(struct seccomp *s)
5cec93c21 Andy Lutomirski  2011-06-05  52  {

:::::: The code at line 31 was first introduced by commit
:::::: a4412fc9486ec85686c6c7929e7e829f62ae377e seccomp,x86,arm,mips,s390: Remove nr parameter from secure_computing

:::::: TO: Andy Lutomirski <luto@amacapital.net>
:::::: CC: Kees Cook <keescook@chromium.org>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 9474 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-02 17:29 [PATCH] percpu_counter: return precise count from __percpu_counter_compare() Waiman Long
  2015-10-02 18:04 ` kbuild test robot
  2015-10-02 18:05 ` kbuild test robot
@ 2015-10-02 18:12 ` kbuild test robot
  2015-10-02 18:15 ` kbuild test robot
  2015-10-02 22:16 ` Dave Chinner
  4 siblings, 0 replies; 18+ messages in thread
From: kbuild test robot @ 2015-10-02 18:12 UTC (permalink / raw)
  To: Waiman Long
  Cc: kbuild-all, Dave Chinner, Tejun Heo, Christoph Lameter,
	linux-kernel, xfs, Scott J Norton, Douglas Hatch, Waiman Long

[-- Attachment #1: Type: text/plain, Size: 18060 bytes --]

Hi Waiman,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore]

config: m68k-sun3_defconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=m68k 

All error/warnings (new ones prefixed by >>):

    {
    ^
   include/linux/jump_label.h:201:42: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline void jump_label_lock(void) {}
                                             ^
   include/linux/jump_label.h:202:44: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline void jump_label_unlock(void) {}
                                               ^
   include/linux/jump_label.h:205:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/jump_label.h:218:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/jump_label.h:223:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/jump_label.h:233:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/jump_label.h:251:1: warning: empty declaration
    struct static_key_true {
    ^
   include/linux/jump_label.h:255:1: warning: empty declaration
    struct static_key_false {
    ^
   In file included from include/linux/vtime.h:4:0,
                    from include/linux/hardirq.h:7,
                    from include/linux/interrupt.h:12,
                    from include/linux/kernel_stat.h:8,
                    from arch/m68k/kernel/asm-offsets.c:15:
   include/linux/context_tracking_state.h:7:1: warning: empty declaration
    struct context_tracking {
    ^
   include/linux/context_tracking_state.h:43:51: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline bool context_tracking_in_user(void) { return false; }
                                                      ^
   include/linux/context_tracking_state.h:44:50: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline bool context_tracking_active(void) { return false; }
                                                     ^
   include/linux/context_tracking_state.h:45:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline bool context_tracking_is_enabled(void) { return false; }
                                                         ^
   include/linux/context_tracking_state.h:46:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline bool context_tracking_cpu_is_enabled(void) { return false; }
                                                             ^
   In file included from include/linux/hardirq.h:7:0,
                    from include/linux/interrupt.h:12,
                    from include/linux/kernel_stat.h:8,
                    from arch/m68k/kernel/asm-offsets.c:15:
   include/linux/vtime.h:10:1: warning: empty declaration
    struct task_struct;
    ^
   include/linux/vtime.h:32:51: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline bool vtime_accounting_enabled(void) { return false; }
                                                      ^
   include/linux/vtime.h:69:64: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline void vtime_task_switch(struct task_struct *prev) { }
                                                                   ^
   include/linux/vtime.h:70:66: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline void vtime_account_system(struct task_struct *tsk) { }
                                                                     ^
   include/linux/vtime.h:71:64: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline void vtime_account_user(struct task_struct *tsk) { }
                                                                   ^
   include/linux/vtime.h:72:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline void vtime_account_irq_enter(struct task_struct *tsk) { }
                                                                        ^
   include/linux/vtime.h:96:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/vtime.h:100:62: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline void vtime_user_enter(struct task_struct *tsk) { }
                                                                 ^
   include/linux/vtime.h:101:61: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline void vtime_user_exit(struct task_struct *tsk) { }
                                                                ^
   include/linux/vtime.h:102:63: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline void vtime_guest_enter(struct task_struct *tsk) { }
                                                                  ^
   include/linux/vtime.h:103:62: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline void vtime_guest_exit(struct task_struct *tsk) { }
                                                                 ^
   include/linux/vtime.h:104:70: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline void vtime_init_idle(struct task_struct *tsk, int cpu) { }
                                                                         ^
   include/linux/vtime.h:110:65: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline void irqtime_account_irq(struct task_struct *tsk) { }
                                                                    ^
   include/linux/vtime.h:114:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/vtime.h:120:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   In file included from arch/m68k/include/asm/hardirq.h:6:0,
                    from include/linux/hardirq.h:8,
                    from include/linux/interrupt.h:12,
                    from include/linux/kernel_stat.h:8,
                    from arch/m68k/kernel/asm-offsets.c:15:
>> arch/m68k/include/asm/irq.h:57:1: warning: empty declaration
    struct irq_data;
    ^
   arch/m68k/include/asm/irq.h:58:1: warning: empty declaration
    struct irq_chip;
    ^
   arch/m68k/include/asm/irq.h:59:1: warning: empty declaration
    struct irq_desc;
    ^
>> arch/m68k/include/asm/irq.h:60:21: error: storage class specified for parameter 'm68k_irq_startup'
    extern unsigned int m68k_irq_startup(struct irq_data *data);
                        ^
>> arch/m68k/include/asm/irq.h:61:21: error: storage class specified for parameter 'm68k_irq_startup_irq'
    extern unsigned int m68k_irq_startup_irq(unsigned int irq);
                        ^
>> arch/m68k/include/asm/irq.h:62:13: error: storage class specified for parameter 'm68k_irq_shutdown'
    extern void m68k_irq_shutdown(struct irq_data *data);
                ^
>> arch/m68k/include/asm/irq.h:63:13: error: storage class specified for parameter 'm68k_setup_auto_interrupt'
    extern void m68k_setup_auto_interrupt(void (*handler)(unsigned int,
                ^
>> arch/m68k/include/asm/irq.h:65:13: error: storage class specified for parameter 'm68k_setup_user_interrupt'
    extern void m68k_setup_user_interrupt(unsigned int vec, unsigned int cnt);
                ^
>> arch/m68k/include/asm/irq.h:66:13: error: storage class specified for parameter 'm68k_setup_irq_controller'
    extern void m68k_setup_irq_controller(struct irq_chip *,
                ^
>> arch/m68k/include/asm/irq.h:70:21: error: storage class specified for parameter 'irq_canonicalize'
    extern unsigned int irq_canonicalize(unsigned int irq);
                        ^
>> arch/m68k/include/asm/irq.h:77:17: error: storage class specified for parameter 'irq_err_count'
    extern atomic_t irq_err_count;
                    ^
   In file included from include/linux/hardirq.h:8:0,
                    from include/linux/interrupt.h:12,
                    from include/linux/kernel_stat.h:8,
                    from arch/m68k/kernel/asm-offsets.c:15:
>> arch/m68k/include/asm/hardirq.h:11:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
>> arch/m68k/include/asm/hardirq.h:18:25: error: storage class specified for parameter 'irq_cpustat_t'
    } ____cacheline_aligned irq_cpustat_t;
                            ^
   In file included from arch/m68k/include/asm/hardirq.h:20:0,
                    from include/linux/hardirq.h:8,
                    from include/linux/interrupt.h:12,
                    from include/linux/kernel_stat.h:8,
                    from arch/m68k/kernel/asm-offsets.c:15:
>> include/linux/irq_cpustat.h:20:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'irq_stat'
    extern irq_cpustat_t irq_stat[];  /* defined in asm/hardirq.h */
                         ^
   In file included from include/linux/interrupt.h:12:0,
                    from include/linux/kernel_stat.h:8,
                    from arch/m68k/kernel/asm-offsets.c:15:
   include/linux/hardirq.h:11:13: error: storage class specified for parameter 'synchronize_irq'
    extern void synchronize_irq(unsigned int irq);
                ^
   include/linux/hardirq.h:12:13: error: storage class specified for parameter 'synchronize_hardirq'
    extern bool synchronize_hardirq(unsigned int irq);
                ^
   include/linux/hardirq.h:17:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/hardirq.h:21:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/hardirq.h:45:13: error: storage class specified for parameter 'irq_enter'
    extern void irq_enter(void);
                ^
   include/linux/hardirq.h:60:13: error: storage class specified for parameter 'irq_exit'
    extern void irq_exit(void);
                ^
   In file included from include/linux/interrupt.h:15:0,
                    from include/linux/kernel_stat.h:8,
                    from arch/m68k/kernel/asm-offsets.c:15:
   include/linux/kref.h:24:1: warning: empty declaration
    struct kref {
    ^
   include/linux/kref.h:33:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/kref.h:42:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/kref.h:70:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/kref.h:98:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/kref.h:118:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/kref.h:137:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/kref.h:168:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   In file included from include/linux/kernel_stat.h:8:0,
                    from arch/m68k/kernel/asm-offsets.c:15:
   include/linux/interrupt.h:87:1: warning: empty declaration
    enum {
    ^
>> include/linux/interrupt.h:92:22: error: expected declaration specifiers or '...' before '*' token
    typedef irqreturn_t (*irq_handler_t)(int, void *);
                         ^
>> include/linux/interrupt.h:110:2: error: unknown type name 'irq_handler_t'
     irq_handler_t  handler;
     ^
   include/linux/interrupt.h:114:2: error: unknown type name 'irq_handler_t'
     irq_handler_t  thread_fn;
     ^
   include/linux/interrupt.h:109:1: warning: empty declaration
    struct irqaction {
    ^
>> include/linux/interrupt.h:124:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'no_action'
    extern irqreturn_t no_action(int cpl, void *dev_id);
                       ^
   include/linux/interrupt.h:127:40: error: unknown type name 'irq_handler_t'
    request_threaded_irq(unsigned int irq, irq_handler_t handler,
                                           ^
   include/linux/interrupt.h:128:8: error: unknown type name 'irq_handler_t'
           irq_handler_t thread_fn,
           ^
   include/linux/interrupt.h:132:31: error: unknown type name 'irq_handler_t'
    request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags,
                                  ^
   include/linux/interrupt.h:139:43: error: unknown type name 'irq_handler_t'
    request_any_context_irq(unsigned int irq, irq_handler_t handler,
                                              ^
   include/linux/interrupt.h:143:38: error: unknown type name 'irq_handler_t'
    request_percpu_irq(unsigned int irq, irq_handler_t handler,
                                         ^
   include/linux/interrupt.h:146:13: error: storage class specified for parameter 'free_irq'
    extern void free_irq(unsigned int, void *);
                ^
   include/linux/interrupt.h:147:13: error: storage class specified for parameter 'free_percpu_irq'
    extern void free_percpu_irq(unsigned int, void __percpu *);
                ^
   include/linux/interrupt.h:149:1: warning: empty declaration
    struct device;
    ^
   include/linux/interrupt.h:153:6: error: unknown type name 'irq_handler_t'
         irq_handler_t handler, irq_handler_t thread_fn,
         ^
   include/linux/interrupt.h:153:29: error: unknown type name 'irq_handler_t'
         irq_handler_t handler, irq_handler_t thread_fn,
                                ^
   include/linux/interrupt.h:158:56: error: unknown type name 'irq_handler_t'
    devm_request_irq(struct device *dev, unsigned int irq, irq_handler_t handler,
                                                           ^
   include/linux/interrupt.h:167:4: error: unknown type name 'irq_handler_t'
       irq_handler_t handler, unsigned long irqflags,
       ^
   include/linux/interrupt.h:170:13: error: storage class specified for parameter 'devm_free_irq'
    extern void devm_free_irq(struct device *dev, unsigned int irq, void *dev_id);
                ^
   include/linux/interrupt.h:190:13: error: storage class specified for parameter 'disable_irq_nosync'
    extern void disable_irq_nosync(unsigned int irq);
                ^
   include/linux/interrupt.h:191:13: error: storage class specified for parameter 'disable_hardirq'
    extern bool disable_hardirq(unsigned int irq);
                ^
   include/linux/interrupt.h:192:13: error: storage class specified for parameter 'disable_irq'
    extern void disable_irq(unsigned int irq);
                ^
   include/linux/interrupt.h:193:13: error: storage class specified for parameter 'disable_percpu_irq'
    extern void disable_percpu_irq(unsigned int irq);
                ^
   include/linux/interrupt.h:194:13: error: storage class specified for parameter 'enable_irq'
    extern void enable_irq(unsigned int irq);
                ^
   include/linux/interrupt.h:195:13: error: storage class specified for parameter 'enable_percpu_irq'
    extern void enable_percpu_irq(unsigned int irq, unsigned int type);
                ^
   include/linux/interrupt.h:196:13: error: storage class specified for parameter 'irq_wake_thread'
    extern void irq_wake_thread(unsigned int irq, void *dev_id);
                ^
   include/linux/interrupt.h:199:13: error: storage class specified for parameter 'suspend_device_irqs'
    extern void suspend_device_irqs(void);
                ^
   include/linux/interrupt.h:200:13: error: storage class specified for parameter 'resume_device_irqs'
    extern void resume_device_irqs(void);
                ^
   include/linux/interrupt.h:214:1: warning: empty declaration
    struct irq_affinity_notify {
    ^
   include/linux/interrupt.h:271:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/interrupt.h:276:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/interrupt.h:281:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/interrupt.h:285:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    static inline int irq_select_affinity(unsigned int irq)  { return 0; }
                                                             ^
   include/linux/interrupt.h:289:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/interrupt.h:295:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/interrupt.h:312:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/interrupt.h:320:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/interrupt.h:328:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
    ^
   include/linux/interrupt.h:336:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
    {
..

vim +125 include/linux/percpu_counter.h

   119		else if (fbc->count < rhs)
   120			return -1;
   121		else
   122			return 0;
   123	}
   124	
 > 125	static inline int __percpu_counter_compare(struct percpu_counter *fbc, s64 rhs,
   126						   s32 batch, s64 *pcnt))
   127	{
   128		return percpu_counter_compare(fbc, rhs);

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 10998 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-02 17:29 [PATCH] percpu_counter: return precise count from __percpu_counter_compare() Waiman Long
                   ` (2 preceding siblings ...)
  2015-10-02 18:12 ` kbuild test robot
@ 2015-10-02 18:15 ` kbuild test robot
  2015-10-02 22:16 ` Dave Chinner
  4 siblings, 0 replies; 18+ messages in thread
From: kbuild test robot @ 2015-10-02 18:15 UTC (permalink / raw)
  To: Waiman Long
  Cc: kbuild-all, Dave Chinner, Tejun Heo, Christoph Lameter,
	linux-kernel, xfs, Scott J Norton, Douglas Hatch, Waiman Long

[-- Attachment #1: Type: text/plain, Size: 40457 bytes --]

Hi Waiman,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore]

config: openrisc-or1ksim_defconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=openrisc 

All error/warnings (new ones prefixed by >>):

   include/linux/sched.h:3179:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   In file included from include/linux/ptrace.h:6:0,
                    from arch/openrisc/kernel/asm-offsets.c:32:
   include/linux/err.h:24:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/err.h:29:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/err.h:34:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/err.h:39:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/err.h:51:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/err.h:57:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   In file included from include/linux/mm.h:15:0,
                    from include/linux/pid_namespace.h:6,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
   include/linux/debug_locks.h:8:1: warning: empty declaration
   include/linux/debug_locks.h:10:12: error: storage class specified for parameter 'debug_locks'
   include/linux/debug_locks.h:11:12: error: storage class specified for parameter 'debug_locks_silent'
   include/linux/debug_locks.h:15:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/debug_locks.h:22:12: error: storage class specified for parameter 'debug_locks_off'
   include/linux/debug_locks.h:48:1: warning: empty declaration
   include/linux/debug_locks.h:57:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/debug_locks.h:61:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/debug_locks.h:66:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/debug_locks.h:71:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   In file included from include/linux/mm.h:17:0,
                    from include/linux/pid_namespace.h:6,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
   include/linux/range.h:4:1: warning: empty declaration
   include/linux/range.h:24:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   In file included from include/linux/mm.h:19:0,
                    from include/linux/pid_namespace.h:6,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
   include/linux/bit_spinlock.h:16:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/bit_spinlock.h:41:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/bit_spinlock.h:57:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/bit_spinlock.h:74:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/bit_spinlock.h:89:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   In file included from include/linux/mm.h:20:0,
                    from include/linux/pid_namespace.h:6,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
   include/linux/shrinker.h:11:1: warning: empty declaration
   include/linux/shrinker.h:49:1: warning: empty declaration
   include/linux/shrinker.h:70:12: error: storage class specified for parameter 'register_shrinker'
   include/linux/shrinker.h:71:13: error: storage class specified for parameter 'unregister_shrinker'
   In file included from include/linux/page_ext.h:5:0,
                    from include/linux/mm.h:22,
                    from include/linux/pid_namespace.h:6,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
   include/linux/stacktrace.h:6:1: warning: empty declaration
   include/linux/stacktrace.h:7:1: warning: empty declaration
   In file included from include/linux/mm.h:22:0,
                    from include/linux/pid_namespace.h:6,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
   include/linux/page_ext.h:7:1: warning: empty declaration
   include/linux/page_ext.h:8:1: warning: empty declaration
   include/linux/page_ext.h:69:1: warning: empty declaration
   include/linux/page_ext.h:72:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page_ext.h:76:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page_ext.h:81:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page_ext.h:85:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   In file included from include/linux/pid_namespace.h:6:0,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
   include/linux/mm.h:25:1: warning: empty declaration
   include/linux/mm.h:26:1: warning: empty declaration
   include/linux/mm.h:27:1: warning: empty declaration
   include/linux/mm.h:28:1: warning: empty declaration
   include/linux/mm.h:29:1: warning: empty declaration
   include/linux/mm.h:30:1: warning: empty declaration
   include/linux/mm.h:31:1: warning: empty declaration
   include/linux/mm.h:34:22: error: storage class specified for parameter 'max_mapnr'
   include/linux/mm.h:37:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/mm.h:44:22: error: storage class specified for parameter 'totalram_pages'
   include/linux/mm.h:45:15: error: storage class specified for parameter 'high_memory'
   include/linux/mm.h:46:12: error: storage class specified for parameter 'page_cluster'
   include/linux/mm.h:49:12: error: storage class specified for parameter 'sysctl_legacy_va_layout'
   In file included from include/asm-generic/pgtable-nopmd.h:6:0,
                    from arch/openrisc/include/asm/pgtable.h:28,
                    from include/linux/mm.h:55,
                    from include/linux/pid_namespace.h:6,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
   include/asm-generic/pgtable-nopud.h:13:31: error: storage class specified for parameter 'pud_t'
   include/asm-generic/pgtable-nopud.h:25:40: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable-nopud.h:26:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable-nopud.h:27:42: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable-nopud.h:28:42: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable-nopud.h:38:21: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
   In file included from arch/openrisc/include/asm/pgtable.h:28:0,
                    from include/linux/mm.h:55,
                    from include/linux/pid_namespace.h:6,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
   include/asm-generic/pgtable-nopmd.h:8:1: warning: empty declaration
   include/asm-generic/pgtable-nopmd.h:17:18: error: expected specifier-qualifier-list before 'pud_t'
   include/asm-generic/pgtable-nopmd.h:17:31: error: storage class specified for parameter 'pmd_t'
>> include/asm-generic/pgtable-nopmd.h:29:34: error: expected ')' before 'pud'
   include/asm-generic/pgtable-nopmd.h:30:33: error: expected ')' before 'pud'
   include/asm-generic/pgtable-nopmd.h:31:37: error: expected ')' before 'pud'
>> include/asm-generic/pgtable-nopmd.h:32:36: error: expected ')' before '*' token
   include/asm-generic/pgtable-nopmd.h:43:21: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
   include/asm-generic/pgtable-nopmd.h:59:51: error: expected declaration specifiers or '...' before 'pmd_t'
   include/asm-generic/pgtable-nopmd.h:60:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   In file included from arch/openrisc/include/asm/pgtable.h:32:0,
                    from include/linux/mm.h:55,
                    from include/linux/pid_namespace.h:6,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
>> arch/openrisc/include/asm/fixmap.h:40:1: warning: empty declaration
>> arch/openrisc/include/asm/fixmap.h:65:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/fixmap.h:82:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   In file included from include/linux/mm.h:55:0,
                    from include/linux/pid_namespace.h:6,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
>> arch/openrisc/include/asm/pgtable.h:46:13: error: storage class specified for parameter 'paging_init'
>> arch/openrisc/include/asm/pgtable.h:203:22: error: storage class specified for parameter 'empty_zero_page'
>> arch/openrisc/include/asm/pgtable.h:237:40: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:238:40: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:239:40: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:240:40: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:241:40: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:242:42: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:243:46: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:246:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:252:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:258:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:264:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:270:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:276:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:282:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:288:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:294:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:300:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:317:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:335:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   arch/openrisc/include/asm/pgtable.h:349:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
>> arch/openrisc/include/asm/pgtable.h:366:34: error: expected ')' before '*' token
>> arch/openrisc/include/asm/pgtable.h:414:14: error: storage class specified for parameter 'swapper_pg_dir'
   arch/openrisc/include/asm/pgtable.h:424:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   In file included from arch/openrisc/include/asm/pgtable.h:441:0,
                    from include/linux/mm.h:55,
                    from include/linux/pid_namespace.h:6,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
   include/asm-generic/pgtable.h:27:12: error: storage class specified for parameter 'ptep_set_access_flags'
   include/asm-generic/pgtable.h:34:29: error: expected declaration specifiers or '...' before 'pmd_t'
   include/asm-generic/pgtable.h:35:6: error: expected declaration specifiers or '...' before 'pmd_t'
>> include/asm-generic/pgtable.h:33:12: error: storage class specified for parameter 'pmdp_set_access_flags'
   include/asm-generic/pgtable.h:42:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:70:10: error: expected declaration specifiers or '...' before 'pmd_t'
   include/asm-generic/pgtable.h:71:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:85:30: error: expected declaration specifiers or '...' before 'pmd_t'
   include/asm-generic/pgtable.h:92:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:127:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:144:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:150:14: error: storage class specified for parameter 'ptep_clear_flush'
   include/asm-generic/pgtable.h:156:14: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pmdp_huge_clear_flush'
>> include/asm-generic/pgtable.h:162:1: warning: empty declaration
   include/asm-generic/pgtable.h:164:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:180:34: error: expected declaration specifiers or '...' before 'pmd_t'
   include/asm-generic/pgtable.h:181:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:189:29: error: expected declaration specifiers or '...' before 'pmd_t'
>> include/asm-generic/pgtable.h:188:13: error: storage class specified for parameter 'pmdp_splitting_flush'
   include/asm-generic/pgtable.h:197:21: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pmdp_collapse_flush'
   include/asm-generic/pgtable.h:209:62: error: expected declaration specifiers or '...' before 'pmd_t'
>> include/asm-generic/pgtable.h:209:13: error: storage class specified for parameter 'pgtable_trans_huge_deposit'
   include/asm-generic/pgtable.h:214:68: error: expected declaration specifiers or '...' before 'pmd_t'
>> include/asm-generic/pgtable.h:214:18: error: storage class specified for parameter 'pgtable_trans_huge_withdraw'
   include/asm-generic/pgtable.h:219:8: error: expected declaration specifiers or '...' before 'pmd_t'
>> include/asm-generic/pgtable.h:218:13: error: storage class specified for parameter 'pmdp_invalidate'
   include/asm-generic/pgtable.h:224:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:237:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
>> include/asm-generic/pgtable.h:249:34: error: expected ')' before 'pmd_a'
   include/asm-generic/pgtable.h:292:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
>> include/asm-generic/pgtable.h:334:26: error: expected ')' before '*' token
   include/asm-generic/pgtable.h:335:26: error: expected ')' before '*' token
   include/asm-generic/pgtable.h:338:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:348:47: error: expected ')' before '*' token
   include/asm-generic/pgtable.h:359:47: error: expected ')' before '*' token
   include/asm-generic/pgtable.h:373:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:385:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:411:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:422:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:466:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
>> include/asm-generic/pgtable.h:470:40: error: expected ')' before 'pmd'
   include/asm-generic/pgtable.h:476:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:480:21: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pmd_mksoft_dirty'
   include/asm-generic/pgtable.h:486:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:491:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:496:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:515:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:525:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:534:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:545:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:570:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:576:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:585:40: error: expected ')' before 'pmd'
   include/asm-generic/pgtable.h:589:45: error: expected ')' before 'pmd'
   include/asm-generic/pgtable.h:594:35: error: expected ')' before 'pmd'
   include/asm-generic/pgtable.h:603:21: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pmd_read_atomic'
   include/asm-generic/pgtable.h:617:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:647:61: error: expected ')' before '*' token
   include/asm-generic/pgtable.h:689:44: error: expected ')' before '*' token
   include/asm-generic/pgtable.h:708:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/asm-generic/pgtable.h:712:38: error: expected ')' before 'pmd'
   include/asm-generic/pgtable.h:726:38: error: expected ')' before '*' token
   include/asm-generic/pgtable.h:730:38: error: expected ')' before '*' token
   include/asm-generic/pgtable.h:734:40: error: expected ')' before '*' token
   include/asm-generic/pgtable.h:738:40: error: expected ')' before '*' token
   In file included from include/linux/mm.h:55:0,
                    from include/linux/pid_namespace.h:6,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
>> arch/openrisc/include/asm/pgtable.h:448:16: error: storage class specified for parameter 'pte_addr_t'
   In file included from include/linux/pid_namespace.h:6:0,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
   include/linux/mm.h:73:22: error: storage class specified for parameter 'sysctl_user_reserve_kbytes'
   include/linux/mm.h:74:22: error: storage class specified for parameter 'sysctl_admin_reserve_kbytes'
   include/linux/mm.h:76:12: error: storage class specified for parameter 'sysctl_overcommit_memory'
   include/linux/mm.h:77:12: error: storage class specified for parameter 'sysctl_overcommit_ratio'
   include/linux/mm.h:78:22: error: storage class specified for parameter 'sysctl_overcommit_kbytes'
   include/linux/mm.h:80:12: error: storage class specified for parameter 'overcommit_ratio_handler'
   include/linux/mm.h:82:12: error: storage class specified for parameter 'overcommit_kbytes_handler'
   include/linux/mm.h:102:27: error: storage class specified for parameter 'vm_area_cachep'
   include/linux/mm.h:209:17: error: storage class specified for parameter 'protection_map'
   include/linux/mm.h:226:1: warning: empty declaration
   include/linux/mm.h:254:7: error: expected declaration specifiers or '...' before 'pmd_t'
   include/linux/mm.h:248:1: warning: empty declaration
   include/linux/mm.h:307:1: warning: empty declaration
   include/linux/mm.h:308:1: warning: empty declaration
   In file included from include/linux/mm.h:317:0,
                    from include/linux/pid_namespace.h:6,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
   include/linux/page-flags.h:74:1: warning: empty declaration
   include/linux/page-flags.h:212:1: warning: empty declaration
   include/linux/page-flags.h:214:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:215:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:215:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:215:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:215:24: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:216:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:216:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:216:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:216:34: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:217:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:218:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:218:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:218:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:218:24: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:218:24: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:218:49: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:219:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:219:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:219:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:219:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:220:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:220:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:220:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:220:26: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:221:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:222:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:222:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:222:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:223:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:223:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:223:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:224:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:224:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:224:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:224:26: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:224:26: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:225:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:225:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:225:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:225:33: error: expected declaration specifiers before ';' token
   include/linux/page-flags.h:226:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:226:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:226:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:226:27: error: expected declaration specifiers before ';' token
   include/linux/page-flags.h:227:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:227:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:227:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:227:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:228:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:228:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:228:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:228:34: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:229:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:231:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:231:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:231:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:238:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:238:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:238:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:238:28: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:239:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:240:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:240:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:240:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:240:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:240:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:241:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:241:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:241:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:241:36: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:247:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:247:36: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:247:36: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:248:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:248:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:248:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:251:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:251:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:251:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:251:28: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:252:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:252:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:252:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:252:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:261:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:261:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:261:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:267:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:267:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:267:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:270:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:270:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:270:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:270:36: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:271:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:274:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:274:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:274:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:274:28: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:275:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:275:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:275:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:284:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:284:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:284:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:292:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:292:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:292:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:324:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:341:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:347:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:365:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:371:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:381:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:392:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:397:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:410:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:410:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:410:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:410:24: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:411:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:411:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:411:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:414:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:486:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:487:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:490:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:534:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:539:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:544:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:561:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:566:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:572:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:580:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:585:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:591:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:601:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:607:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:613:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:619:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   include/linux/page-flags.h:669:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
   In file included from include/linux/mm.h:318:0,
                    from include/linux/pid_namespace.h:6,
                    from include/linux/ptrace.h:8,
                    from arch/openrisc/kernel/asm-offsets.c:32:
   include/linux/huge_mm.h:6:34: error: expected declaration specifiers or '...' before 'pmd_t'
>> include/linux/huge_mm.h:4:12: error: storage class specified for parameter 'do_huge_pmd_anonymous_page'
   include/linux/huge_mm.h:9:5: error: expected declaration specifiers or '...' before 'pmd_t'
   include/linux/huge_mm.h:9:21: error: expected declaration specifiers or '...' before 'pmd_t'

vim +29 include/asm-generic/pgtable-nopmd.h

^1da177e4 Linus Torvalds 2005-04-16   2  #define _PGTABLE_NOPMD_H
^1da177e4 Linus Torvalds 2005-04-16   3  
^1da177e4 Linus Torvalds 2005-04-16   4  #ifndef __ASSEMBLY__
^1da177e4 Linus Torvalds 2005-04-16   5  
^1da177e4 Linus Torvalds 2005-04-16   6  #include <asm-generic/pgtable-nopud.h>
^1da177e4 Linus Torvalds 2005-04-16   7  
34ee55014 Andrew Morton  2008-07-28  @8  struct mm_struct;
34ee55014 Andrew Morton  2008-07-28   9  
^1da177e4 Linus Torvalds 2005-04-16  10  #define __PAGETABLE_PMD_FOLDED
^1da177e4 Linus Torvalds 2005-04-16  11  
^1da177e4 Linus Torvalds 2005-04-16  12  /*
^1da177e4 Linus Torvalds 2005-04-16  13   * Having the pmd type consist of a pud gets the size right, and allows
^1da177e4 Linus Torvalds 2005-04-16  14   * us to conceptually access the pud entry that this pmd is folded into
^1da177e4 Linus Torvalds 2005-04-16  15   * without casting.
^1da177e4 Linus Torvalds 2005-04-16  16   */
^1da177e4 Linus Torvalds 2005-04-16  17  typedef struct { pud_t pud; } pmd_t;
^1da177e4 Linus Torvalds 2005-04-16  18  
^1da177e4 Linus Torvalds 2005-04-16  19  #define PMD_SHIFT	PUD_SHIFT
^1da177e4 Linus Torvalds 2005-04-16  20  #define PTRS_PER_PMD	1
^1da177e4 Linus Torvalds 2005-04-16  21  #define PMD_SIZE  	(1UL << PMD_SHIFT)
^1da177e4 Linus Torvalds 2005-04-16  22  #define PMD_MASK  	(~(PMD_SIZE-1))
^1da177e4 Linus Torvalds 2005-04-16  23  
^1da177e4 Linus Torvalds 2005-04-16  24  /*
^1da177e4 Linus Torvalds 2005-04-16  25   * The "pud_xxx()" functions here are trivial for a folded two-level
^1da177e4 Linus Torvalds 2005-04-16  26   * setup: the pmd is never bad, and a pmd always exists (as it's folded
^1da177e4 Linus Torvalds 2005-04-16  27   * into the pud entry)
^1da177e4 Linus Torvalds 2005-04-16  28   */
^1da177e4 Linus Torvalds 2005-04-16 @29  static inline int pud_none(pud_t pud)		{ return 0; }
^1da177e4 Linus Torvalds 2005-04-16  30  static inline int pud_bad(pud_t pud)		{ return 0; }
^1da177e4 Linus Torvalds 2005-04-16  31  static inline int pud_present(pud_t pud)	{ return 1; }
^1da177e4 Linus Torvalds 2005-04-16 @32  static inline void pud_clear(pud_t *pud)	{ }
^1da177e4 Linus Torvalds 2005-04-16  33  #define pmd_ERROR(pmd)				(pud_ERROR((pmd).pud))
^1da177e4 Linus Torvalds 2005-04-16  34  
^1da177e4 Linus Torvalds 2005-04-16  35  #define pud_populate(mm, pmd, pte)		do { } while (0)

:::::: The code at line 29 was first introduced by commit
:::::: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:::::: TO: Linus Torvalds <torvalds@ppc970.osdl.org>
:::::: CC: Linus Torvalds <torvalds@ppc970.osdl.org>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 6888 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-02 17:29 [PATCH] percpu_counter: return precise count from __percpu_counter_compare() Waiman Long
                   ` (3 preceding siblings ...)
  2015-10-02 18:15 ` kbuild test robot
@ 2015-10-02 22:16 ` Dave Chinner
  2015-10-05 23:02   ` Waiman Long
  4 siblings, 1 reply; 18+ messages in thread
From: Dave Chinner @ 2015-10-02 22:16 UTC (permalink / raw)
  To: Waiman Long
  Cc: Tejun Heo, Christoph Lameter, linux-kernel, xfs, Scott J Norton,
	Douglas Hatch

On Fri, Oct 02, 2015 at 01:29:57PM -0400, Waiman Long wrote:
> In __percpu_counter_compare(), if the current imprecise count is
> within (batch*nr_cpus) of the input value to be compared, a call
> to percpu_counter_sum() will be made to get the precise count. The
> percpu_counter_sum() call, however, can be expensive especially on
> large systems where there are a lot of CPUs. Large systems also make
> it more likely that percpu_counter_sum() will be called.
> 
> The xfs_mod_fdblocks() function calls __percpu_counter_compare()
> twice. First to see if a smaller batch size should be used for
> __percpu_counter_add() and the second call to compare the actual
> size needed. This can potentially lead to 2 calls to the expensive
> percpu_counter_sum() function.

There should not be that much overhead in __percpu_counter_compare()
through this path in normal operation. The slow path is only taken
as you near ENOSPC...

> This patch added an extra argument to __percpu_counter_compare()
> to return the precise count, if computed. The caller will need to
> initialize it to an invalid value that it can tell if the precise
> count is being returned.

This doesn't work. ENOSPC detection is a lockless algorithm that
requires absolute precision. Assuming the XFS_ALLOC_SET_ASIDE()
definition of ENOSPC is 0 blocks free, your change allows this race:

free space: 1 block

thread 1		thread 2			free space
allocate 1 block	allocate 1 block		  1
sample pcount = 1					  1
			sample pcount = 1		  1
add fdblocks, -1, 1)					  0
			add fdblocks, -1, 1)		  -1
if (pcount - 1 >= 0)	if (pcount - 1 >= 0)
   OK!			    OK!				  -1

So, we've just failed to detect ENOSPC correct. One of those two
threads should have returned ENOSPC and failed the allocation,
but instead we've just allowed XFS to allocate a block that doesn't
exist. Hence we have to resample the percpu counter after the
modification to ensure that we don't miss this race condition.

Sure, the curent code could race on the second comparisions and
return ENOSPC to both threads, but that is a perfectly OK thing
to do. It is vitally important that we don't oversubscribe
filesystem space, because that will lead to all sorts of other
problems (deadlocks, hangs, shutdowns, etc) that are very difficult
to identify the cause of.

FWIW, I'm guessing that you didn't run this patch through xfstests?
xfstests will find these ENOSPC accounting bugs, and usually quite
quickly...

> Running the AIM7 disk workload with XFS filesystem, the jobs/min
> on a 40-core 80-thread 4-socket Haswell-EX system increases from
> 3805k to 4276k (12% increase) with this patch applied. As measured
> by the perf tool, the %CPU cycle consumed by __percpu_counter_sum()
> decreases from 12.64% to 7.08%.

XFS should only hit the slow __percpu_counter_sum() path patch as
the fs gets close to ENOSPC, which for your system will be less
than:

threshold = num_online_cpus * XFS_FDBLOCKS_BATCH * 2 blocks
	  = 80 * 1024 * 2 blocks
	  = 160,000 blocks
	  = 640MB of disk space.

Having less than 1GB of free space in an XFS filesystem is
considered to be "almost ENOSPC" - when you have TB to PB of space,
less than 1GB really "moments before ENOSPC".

XFS trades off low overhead for fast path allocation  with slowdowns
as we near ENOSPC in allocation routines. It gets harder to find
contiguous free space, files get more fragmented, IO takes longer
because we seek more, etc. Hence we accept that performance slows
down as as the need for precision increases as we near ENOSPC.

I'd suggest you retry your benchmark with larger filesystems, and
see what happens...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-02 22:16 ` Dave Chinner
@ 2015-10-05 23:02   ` Waiman Long
  2015-10-06  0:25     ` Dave Chinner
  0 siblings, 1 reply; 18+ messages in thread
From: Waiman Long @ 2015-10-05 23:02 UTC (permalink / raw)
  To: Dave Chinner
  Cc: Tejun Heo, Christoph Lameter, linux-kernel, xfs, Scott J Norton,
	Douglas Hatch

On 10/02/2015 06:16 PM, Dave Chinner wrote:
> On Fri, Oct 02, 2015 at 01:29:57PM -0400, Waiman Long wrote:
>> In __percpu_counter_compare(), if the current imprecise count is
>> within (batch*nr_cpus) of the input value to be compared, a call
>> to percpu_counter_sum() will be made to get the precise count. The
>> percpu_counter_sum() call, however, can be expensive especially on
>> large systems where there are a lot of CPUs. Large systems also make
>> it more likely that percpu_counter_sum() will be called.
>>
>> The xfs_mod_fdblocks() function calls __percpu_counter_compare()
>> twice. First to see if a smaller batch size should be used for
>> __percpu_counter_add() and the second call to compare the actual
>> size needed. This can potentially lead to 2 calls to the expensive
>> percpu_counter_sum() function.
> There should not be that much overhead in __percpu_counter_compare()
> through this path in normal operation. The slow path is only taken
> as you near ENOSPC...

Yes, it is for optimizing the case there the filesystem is near ENOSP.

>> This patch added an extra argument to __percpu_counter_compare()
>> to return the precise count, if computed. The caller will need to
>> initialize it to an invalid value that it can tell if the precise
>> count is being returned.
> This doesn't work. ENOSPC detection is a lockless algorithm that
> requires absolute precision. Assuming the XFS_ALLOC_SET_ASIDE()
> definition of ENOSPC is 0 blocks free, your change allows this race:
>
> free space: 1 block
>
> thread 1		thread 2			free space
> allocate 1 block	allocate 1 block		  1
> sample pcount = 1					  1
> 			sample pcount = 1		  1
> add fdblocks, -1, 1)					  0
> 			add fdblocks, -1, 1)		  -1
> if (pcount - 1>= 0)	if (pcount - 1>= 0)
>     OK!			    OK!				  -1
>
> So, we've just failed to detect ENOSPC correct. One of those two
> threads should have returned ENOSPC and failed the allocation,
> but instead we've just allowed XFS to allocate a block that doesn't
> exist. Hence we have to resample the percpu counter after the
> modification to ensure that we don't miss this race condition.
>
> Sure, the curent code could race on the second comparisions and
> return ENOSPC to both threads, but that is a perfectly OK thing
> to do. It is vitally important that we don't oversubscribe
> filesystem space, because that will lead to all sorts of other
> problems (deadlocks, hangs, shutdowns, etc) that are very difficult
> to identify the cause of.
>
> FWIW, I'm guessing that you didn't run this patch through xfstests?
> xfstests will find these ENOSPC accounting bugs, and usually quite
> quickly...

Thanks for the review. I did miss the case that there was a race 
condition here. I also haven't run xfstests with this patch. I will do 
so next time.

>> Running the AIM7 disk workload with XFS filesystem, the jobs/min
>> on a 40-core 80-thread 4-socket Haswell-EX system increases from
>> 3805k to 4276k (12% increase) with this patch applied. As measured
>> by the perf tool, the %CPU cycle consumed by __percpu_counter_sum()
>> decreases from 12.64% to 7.08%.
> XFS should only hit the slow __percpu_counter_sum() path patch as
> the fs gets close to ENOSPC, which for your system will be less
> than:
>
> threshold = num_online_cpus * XFS_FDBLOCKS_BATCH * 2 blocks
> 	  = 80 * 1024 * 2 blocks
> 	  = 160,000 blocks
> 	  = 640MB of disk space.
>
> Having less than 1GB of free space in an XFS filesystem is
> considered to be "almost ENOSPC" - when you have TB to PB of space,
> less than 1GB really "moments before ENOSPC".

We have systems with more than 500 CPUs (HT on). I think SGI has systems 
with thousands of CPUs. For those large system, the slowpath will be 
triggered if there is less than 4G or 10G for those thousand CPUs 
systems. What I am trying to do with my patch is to reduce the 
performance overhead in those cases. I have no worry for systems that 
have only a few CPUs. In essence, the per-cpu counter code doesn't scale 
well for systems with large number of CPUs.

> XFS trades off low overhead for fast path allocation  with slowdowns
> as we near ENOSPC in allocation routines. It gets harder to find
> contiguous free space, files get more fragmented, IO takes longer
> because we seek more, etc. Hence we accept that performance slows
> down as as the need for precision increases as we near ENOSPC.
>
> I'd suggest you retry your benchmark with larger filesystems, and
> see what happens...

I don't think I am going to see the slowdown that I observed on larger 
filesystems with more free space. However, I still think that doing 2 
precise count computations is wasteful. I am planning to rework my patch 
to disable precise count for the first comparison in xfs_mod_fdblocks as 
that comparison is used to gauge how far it is from ENOSPC. So we don't 
really need to get the precise count as long as number of CPUs are taken 
into consideration in the comparison. This change should enable the new 
patch to have similar performance overhead reduction effect as the old 
one without the racing condition you mentioned above.

Cheers,
Longman


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-02 18:04 ` kbuild test robot
@ 2015-10-05 23:03   ` Waiman Long
  0 siblings, 0 replies; 18+ messages in thread
From: Waiman Long @ 2015-10-05 23:03 UTC (permalink / raw)
  To: kbuild test robot
  Cc: kbuild-all, Dave Chinner, Tejun Heo, Christoph Lameter,
	linux-kernel, xfs, Scott J Norton, Douglas Hatch

On 10/02/2015 02:04 PM, kbuild test robot wrote:
> Hi Waiman,
>
> [auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore]
>
> config: ia64-allnoconfig (attached as .config)
> reproduce:
>          wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>          chmod +x ~/bin/make.cross
>          # save the attached .config to linux build tree
>          make.cross ARCH=ia64
>
> All error/warnings (new ones prefixed by>>):
>
>

Sorry for the build error. There was a typo in the non-SMP portion of 
the code change. I will fix that in the next version.

Cheers,
Longman

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-05 23:02   ` Waiman Long
@ 2015-10-06  0:25     ` Dave Chinner
  2015-10-06 17:33       ` Waiman Long
  0 siblings, 1 reply; 18+ messages in thread
From: Dave Chinner @ 2015-10-06  0:25 UTC (permalink / raw)
  To: Waiman Long
  Cc: Tejun Heo, Christoph Lameter, linux-kernel, xfs, Scott J Norton,
	Douglas Hatch

On Mon, Oct 05, 2015 at 07:02:21PM -0400, Waiman Long wrote:
> On 10/02/2015 06:16 PM, Dave Chinner wrote:
> >On Fri, Oct 02, 2015 at 01:29:57PM -0400, Waiman Long wrote:
> >>In __percpu_counter_compare(), if the current imprecise count is
> >>within (batch*nr_cpus) of the input value to be compared, a call
> >>to percpu_counter_sum() will be made to get the precise count. The
> >>percpu_counter_sum() call, however, can be expensive especially on
> >>large systems where there are a lot of CPUs. Large systems also make
> >>it more likely that percpu_counter_sum() will be called.
> >>
> >>The xfs_mod_fdblocks() function calls __percpu_counter_compare()
> >>twice. First to see if a smaller batch size should be used for
> >>__percpu_counter_add() and the second call to compare the actual
> >>size needed. This can potentially lead to 2 calls to the expensive
> >>percpu_counter_sum() function.
> >There should not be that much overhead in __percpu_counter_compare()
> >through this path in normal operation. The slow path is only taken
> >as you near ENOSPC...
> 
> Yes, it is for optimizing the case there the filesystem is near ENOSP.
....
> >Having less than 1GB of free space in an XFS filesystem is
> >considered to be "almost ENOSPC" - when you have TB to PB of space,
> >less than 1GB really "moments before ENOSPC".
> 
> We have systems with more than 500 CPUs (HT on). I think SGI has
> systems with thousands of CPUs. For those large system, the slowpath
> will be triggered if there is less than 4G or 10G for those thousand
> CPUs systems.

yes, I'm well aware of this. But systems with hundreds to thousands
of CPUs simply do not operate their storage at this capacity.
They'll have hundreds of TB or PBs of storage attached, so if we
trigger the slow path at 10GB of free space, we are talking about
having already used > 99.9% of that capacity.

In which case, they are already in a world of pain because
filesystem allocation performance starts to degrade at >90%
capacity, and we start cutting back preallocations at >95% capacity,
and we really start to throttle ispace allocations to their
minimum possible sizes at >99% capacity. IOWs, hitting this slow
path at >99.9% capacity is really irrelevant....


> What I am trying to do with my patch is to reduce the
> performance overhead in those cases. I have no worry for systems
> that have only a few CPUs. In essence, the per-cpu counter code
> doesn't scale well for systems with large number of CPUs.

Maybe so, but we don't tend ot optimise slow paths - we trade off a
really fast fast path for a slow, more complex slow path all over
the place. Not just in XFS, but all over the kernel.

> >XFS trades off low overhead for fast path allocation  with slowdowns
> >as we near ENOSPC in allocation routines. It gets harder to find
> >contiguous free space, files get more fragmented, IO takes longer
> >because we seek more, etc. Hence we accept that performance slows
> >down as as the need for precision increases as we near ENOSPC.
> >
> >I'd suggest you retry your benchmark with larger filesystems, and
> >see what happens...
> 
> I don't think I am going to see the slowdown that I observed on
> larger filesystems with more free space.

So there is no problem that needs fixing.... ;)

> However, I still think that
> doing 2 precise count computations is wasteful.

I really don't care about the CPU overhead, because it's far more
important that:

	1) the zero threshold detection is precise and correct;
	2) the fast path is really fast; and
	3) I understand the code well enough to be able to debug
	   and maintain it.

> I am planning to rework my patch to disable precise count for the
> first comparison in xfs_mod_fdblocks as that comparison is used to
> gauge how far it is from ENOSPC.  So we don't really need to get
> the precise count as long as number of CPUs are taken into
> consideration in the comparison.

I think you are looking in the wrong place. There is nothing
wrong with XFS doing two compares here. If we are hitting the
__percpu_counter_compare() slow path too much, then we should be
understanding exactly why that slow path is being hit so hard so
often. I don't see any analysis of the actual per-cpu counter
behaviour and why the slow path is being taken so often....

Indeed, have you considered using something like this in the precise
path of __percpu_counter_compare() rather than percpu_counter_sum():

/*
 * Aggregate the per-cpu counter magazines back into the global
 * counter. This avoids the need for repeated compare operations to
 * run the slow path when the majority of the counter value is held
 * in the per-cpu magazines. Folding them back into the global
 * counter means we will continue to hit the fast
 * percpu_counter_read() path until the counter value falls
 * completely within the comparison limit passed to
 * __percpu_counter_compare().
 */
static s64 percpu_counter_aggregate(struct percpu_counter *fbc)
{
	s64 ret;
	int cpu;
	unsigned long flags;

	raw_spin_lock_irqsave(&fbc->lock, flags);
	ret = fbc->count;
	for_each_online_cpu(cpu) {
		s32 count = __this_cpu_read(*fbc->counters);
                ret += count;
		__this_cpu_sub(*fbc->counters, count)
	}
	fbc->count = ret;
	raw_spin_unlock_irqrestore(&fbc->lock, flags);
	return ret;
}


Some perspective: you wouldn't have seen this behaviour with the
previous per-cpu counter code in XFS near ENOSPC. By the time it got
this close to ENOSPC it was completely serialising all access to the
free space counters with a mutex and then doing per-cpu sums under
that mutex (see commit 20b6428 ("[XFS] Reduction global superblock
lock contention near ENOSPC.").  Hence it wouldn't have appeared in
your profiles, even though it was much worse in terms of contention
and lock hold times than the current code is.

This looks to be the same fundamental problem - the per-cpu counter
values are not being managed in a way that reduces minimises precise
comparison overhead. Making the above change will tell us whether
this is the case or not...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-06  0:25     ` Dave Chinner
@ 2015-10-06 17:33       ` Waiman Long
  2015-10-06 21:30         ` Dave Chinner
  0 siblings, 1 reply; 18+ messages in thread
From: Waiman Long @ 2015-10-06 17:33 UTC (permalink / raw)
  To: Dave Chinner
  Cc: Tejun Heo, Christoph Lameter, linux-kernel, xfs, Scott J Norton,
	Douglas Hatch

On 10/05/2015 08:25 PM, Dave Chinner wrote:
> On Mon, Oct 05, 2015 at 07:02:21PM -0400, Waiman Long wrote:
> ....
>>> Having less than 1GB of free space in an XFS filesystem is
>>> considered to be "almost ENOSPC" - when you have TB to PB of space,
>>> less than 1GB really "moments before ENOSPC".
>> We have systems with more than 500 CPUs (HT on). I think SGI has
>> systems with thousands of CPUs. For those large system, the slowpath
>> will be triggered if there is less than 4G or 10G for those thousand
>> CPUs systems.
> yes, I'm well aware of this. But systems with hundreds to thousands
> of CPUs simply do not operate their storage at this capacity.
> They'll have hundreds of TB or PBs of storage attached, so if we
> trigger the slow path at 10GB of free space, we are talking about
> having already used>  99.9% of that capacity.
>
> In which case, they are already in a world of pain because
> filesystem allocation performance starts to degrade at>90%
> capacity, and we start cutting back preallocations at>95% capacity,
> and we really start to throttle ispace allocations to their
> minimum possible sizes at>99% capacity. IOWs, hitting this slow
> path at>99.9% capacity is really irrelevant....
>

In the production environment, we do expect to see large storage 
attached to those big machines. However, in the testing environment, we 
may have such large pool of disks to be used. Alternatively, a user may 
create a small filesystem partition for certain specific use. Under 
those circumstances, the slowpath may be triggered.

>> What I am trying to do with my patch is to reduce the
>> performance overhead in those cases. I have no worry for systems
>> that have only a few CPUs. In essence, the per-cpu counter code
>> doesn't scale well for systems with large number of CPUs.
> Maybe so, but we don't tend ot optimise slow paths - we trade off a
> really fast fast path for a slow, more complex slow path all over
> the place. Not just in XFS, but all over the kernel.

I am not proposing any change to the fast path and they should have the 
same performance as before.

>>> XFS trades off low overhead for fast path allocation  with slowdowns
>>> as we near ENOSPC in allocation routines. It gets harder to find
>>> contiguous free space, files get more fragmented, IO takes longer
>>> because we seek more, etc. Hence we accept that performance slows
>>> down as as the need for precision increases as we near ENOSPC.
>>>
>>> I'd suggest you retry your benchmark with larger filesystems, and
>>> see what happens...
>> I don't think I am going to see the slowdown that I observed on
>> larger filesystems with more free space.
> So there is no problem that needs fixing.... ;)
>

Well, I am still worrying that corner cases when the slowpath is 
triggered. I would like to make it perform better in those cases.


>> However, I still think that
>> doing 2 precise count computations is wasteful.
> I really don't care about the CPU overhead, because it's far more
> important that:
>
> 	1) the zero threshold detection is precise and correct;
> 	2) the fast path is really fast; and
> 	3) I understand the code well enough to be able to debug
> 	   and maintain it.

I completely agree with that:-)

>> I am planning to rework my patch to disable precise count for the
>> first comparison in xfs_mod_fdblocks as that comparison is used to
>> gauge how far it is from ENOSPC.  So we don't really need to get
>> the precise count as long as number of CPUs are taken into
>> consideration in the comparison.
> I think you are looking in the wrong place. There is nothing
> wrong with XFS doing two compares here. If we are hitting the
> __percpu_counter_compare() slow path too much, then we should be
> understanding exactly why that slow path is being hit so hard so
> often. I don't see any analysis of the actual per-cpu counter
> behaviour and why the slow path is being taken so often....

I am thinking of making the following changes:

  fs/xfs/xfs_mount.c |   11 ++++++-----
  1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index bf92e0c..bb2e0ef 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -1183,12 +1183,13 @@ xfs_mod_fdblocks(
       * Taking blocks away, need to be more accurate the closer we
       * are to zero.
       *
-     * If the counter has a value of less than 2 * max batch size,
-     * then make everything serialise as we are real close to
-     * ENOSPC.
+     * The maximum error of imprecise counter is (nr_cpus * batch size).
+     * If the imprecise counter has a value less than (nr_cpus + 2) *
+     * max batch size, then make everything serialise as we may be real
+     * close to ENOSPC.
       */
-    if (__percpu_counter_compare(&mp->m_fdblocks, 2 * XFS_FDBLOCKS_BATCH,
-                     XFS_FDBLOCKS_BATCH) < 0)
+    if (percpu_counter_read(&mp->m_fdblocks) <
+       (num_online_cpus() + 2) * XFS_FDBLOCKS_BATCH)
          batch = 1;
      else
          batch = XFS_FDBLOCKS_BATCH;
-- 

Please let me know if you think that is acceptable to you.

> Indeed, have you considered using something like this in the precise
> path of __percpu_counter_compare() rather than percpu_counter_sum():
>
> /*
>   * Aggregate the per-cpu counter magazines back into the global
>   * counter. This avoids the need for repeated compare operations to
>   * run the slow path when the majority of the counter value is held
>   * in the per-cpu magazines. Folding them back into the global
>   * counter means we will continue to hit the fast
>   * percpu_counter_read() path until the counter value falls
>   * completely within the comparison limit passed to
>   * __percpu_counter_compare().
>   */
> static s64 percpu_counter_aggregate(struct percpu_counter *fbc)
> {
> 	s64 ret;
> 	int cpu;
> 	unsigned long flags;
>
> 	raw_spin_lock_irqsave(&fbc->lock, flags);
> 	ret = fbc->count;
> 	for_each_online_cpu(cpu) {
> 		s32 count = __this_cpu_read(*fbc->counters);
>                  ret += count;
> 		__this_cpu_sub(*fbc->counters, count)
> 	}
> 	fbc->count = ret;
> 	raw_spin_unlock_irqrestore(&fbc->lock, flags);
> 	return ret;
> }

I don't think that will work as some other CPUs may change the percpu 
counters values between percpu_counter_aggregate() and 
__percpu_counter_compare(). To be safe, the precise counter has to be 
compted whenever the comparison value difference is less than nr_cpus * 
batch size.

> Some perspective: you wouldn't have seen this behaviour with the
> previous per-cpu counter code in XFS near ENOSPC. By the time it got
> this close to ENOSPC it was completely serialising all access to the
> free space counters with a mutex and then doing per-cpu sums under
> that mutex (see commit 20b6428 ("[XFS] Reduction global superblock
> lock contention near ENOSPC.").  Hence it wouldn't have appeared in
> your profiles, even though it was much worse in terms of contention
> and lock hold times than the current code is.
>
> This looks to be the same fundamental problem - the per-cpu counter
> values are not being managed in a way that reduces minimises precise
> comparison overhead. Making the above change will tell us whether
> this is the case or not...

I have some thoughts on how to reduce precise comparison overhead, but I 
need more time to work out the details.

Cheers,
Longman

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-06 17:33       ` Waiman Long
@ 2015-10-06 21:30         ` Dave Chinner
  2015-10-07 20:00           ` Waiman Long
  0 siblings, 1 reply; 18+ messages in thread
From: Dave Chinner @ 2015-10-06 21:30 UTC (permalink / raw)
  To: Waiman Long
  Cc: Tejun Heo, Christoph Lameter, linux-kernel, xfs, Scott J Norton,
	Douglas Hatch

On Tue, Oct 06, 2015 at 01:33:21PM -0400, Waiman Long wrote:
> On 10/05/2015 08:25 PM, Dave Chinner wrote:
> >On Mon, Oct 05, 2015 at 07:02:21PM -0400, Waiman Long wrote:
> >....
> >>>Having less than 1GB of free space in an XFS filesystem is
> >>>considered to be "almost ENOSPC" - when you have TB to PB of space,
> >>>less than 1GB really "moments before ENOSPC".
> >>We have systems with more than 500 CPUs (HT on). I think SGI has
> >>systems with thousands of CPUs. For those large system, the slowpath
> >>will be triggered if there is less than 4G or 10G for those thousand
> >>CPUs systems.
> >yes, I'm well aware of this. But systems with hundreds to thousands
> >of CPUs simply do not operate their storage at this capacity.
> >They'll have hundreds of TB or PBs of storage attached, so if we
> >trigger the slow path at 10GB of free space, we are talking about
> >having already used>  99.9% of that capacity.
> >
> >In which case, they are already in a world of pain because
> >filesystem allocation performance starts to degrade at>90%
> >capacity, and we start cutting back preallocations at>95% capacity,
> >and we really start to throttle ispace allocations to their
> >minimum possible sizes at>99% capacity. IOWs, hitting this slow
> >path at>99.9% capacity is really irrelevant....
> >
> 
> In the production environment, we do expect to see large storage
> attached to those big machines. However, in the testing environment,
> we may have such large pool of disks to be used. Alternatively, a
> user may create a small filesystem partition for certain specific
> use. Under those circumstances, the slowpath may be triggered.

Yes, it may be, but that does not mean we should optimise for it.
If you are doing filesystem scalability testing on small filesystems
near capacity, then your testing methodology is needs fixing. Not
the code.

> >>>XFS trades off low overhead for fast path allocation  with slowdowns
> >>>as we near ENOSPC in allocation routines. It gets harder to find
> >>>contiguous free space, files get more fragmented, IO takes longer
> >>>because we seek more, etc. Hence we accept that performance slows
> >>>down as as the need for precision increases as we near ENOSPC.
> >>>
> >>>I'd suggest you retry your benchmark with larger filesystems, and
> >>>see what happens...
> >>I don't think I am going to see the slowdown that I observed on
> >>larger filesystems with more free space.
> >So there is no problem that needs fixing.... ;)
> 
> Well, I am still worrying that corner cases when the slowpath is
> triggered. I would like to make it perform better in those cases.

It's a pretty damn small slowdown in your somewhat extreme,
artificial test. Show me a real world production system that runs
small fileystems permanently at >99% filesystem capacity, and them
maybe vwe've got something that needs changing.

> >>gauge how far it is from ENOSPC.  So we don't really need to get
> >>the precise count as long as number of CPUs are taken into
> >>consideration in the comparison.
> >I think you are looking in the wrong place. There is nothing
> >wrong with XFS doing two compares here. If we are hitting the
> >__percpu_counter_compare() slow path too much, then we should be
> >understanding exactly why that slow path is being hit so hard so
> >often. I don't see any analysis of the actual per-cpu counter
> >behaviour and why the slow path is being taken so often....
> 
> I am thinking of making the following changes:

No. Please test the change to the per-cpu counters that I suggested:

> >/*
> >  * Aggregate the per-cpu counter magazines back into the global
> >  * counter. This avoids the need for repeated compare operations to
> >  * run the slow path when the majority of the counter value is held
> >  * in the per-cpu magazines. Folding them back into the global
> >  * counter means we will continue to hit the fast
> >  * percpu_counter_read() path until the counter value falls
> >  * completely within the comparison limit passed to
> >  * __percpu_counter_compare().
> >  */
> >static s64 percpu_counter_aggregate(struct percpu_counter *fbc)
> >{
> >	s64 ret;
> >	int cpu;
> >	unsigned long flags;
> >
> >	raw_spin_lock_irqsave(&fbc->lock, flags);
> >	ret = fbc->count;
> >	for_each_online_cpu(cpu) {
> >		s32 count = __this_cpu_read(*fbc->counters);
> >                 ret += count;
> >		__this_cpu_sub(*fbc->counters, count)
> >	}
> >	fbc->count = ret;
> >	raw_spin_unlock_irqrestore(&fbc->lock, flags);
> >	return ret;
> >}
> 
> I don't think that will work as some other CPUs may change the
> percpu counters values between percpu_counter_aggregate() and
> __percpu_counter_compare().  To be safe, the precise counter has to
> be compted whenever the comparison value difference is less than
> nr_cpus * batch size.

Well, yes. Why do you think the above function does the same
function as percpu_counter_sum()? So that the percpu_counter_sum()
call *inside* __percpu_counter_compare() can be replaced by this
call. i.e.

			return -1;
	}
	/* Need to use precise count */
-	count = percpu_counter_sum(fbc);
+	count = percpu_counter_aggregate(fbc);
	if (count > rhs)
		return 1;
	else if (count < rhs)

Please think about what I'm saying rather than dismissing it without
first understanding my suggestions.

> I have some thoughts on how to reduce precise comparison overhead,
> but I need more time to work out the details.

We don't need something "smart" that only 2 people understand
properly that turns the per-cpu counters into a regression-prone,
unmaintainable mess like all the locking code has become.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-06 21:30         ` Dave Chinner
@ 2015-10-07 20:00           ` Waiman Long
  2015-10-07 23:04             ` Dave Chinner
  0 siblings, 1 reply; 18+ messages in thread
From: Waiman Long @ 2015-10-07 20:00 UTC (permalink / raw)
  To: Dave Chinner
  Cc: Tejun Heo, Christoph Lameter, linux-kernel, xfs, Scott J Norton,
	Douglas Hatch

On 10/06/2015 05:30 PM, Dave Chinner wrote:
> On Tue, Oct 06, 2015 at 01:33:21PM -0400, Waiman Long wrote:
> Yes, it may be, but that does not mean we should optimise for it.
> If you are doing filesystem scalability testing on small filesystems
> near capacity, then your testing methodology is needs fixing. Not
> the code.
>
>>>>> XFS trades off low overhead for fast path allocation  with slowdowns
>>>>> as we near ENOSPC in allocation routines. It gets harder to find
>>>>> contiguous free space, files get more fragmented, IO takes longer
>>>>> because we seek more, etc. Hence we accept that performance slows
>>>>> down as as the need for precision increases as we near ENOSPC.
>>>>>
>>>>> I'd suggest you retry your benchmark with larger filesystems, and
>>>>> see what happens...
>>>> I don't think I am going to see the slowdown that I observed on
>>>> larger filesystems with more free space.
>>> So there is no problem that needs fixing.... ;)
>> Well, I am still worrying that corner cases when the slowpath is
>> triggered. I would like to make it perform better in those cases.
> It's a pretty damn small slowdown in your somewhat extreme,
> artificial test. Show me a real world production system that runs
> small fileystems permanently at>99% filesystem capacity, and them
> maybe vwe've got something that needs changing.
>
>>>> gauge how far it is from ENOSPC.  So we don't really need to get
>>>> the precise count as long as number of CPUs are taken into
>>>> consideration in the comparison.
>>> I think you are looking in the wrong place. There is nothing
>>> wrong with XFS doing two compares here. If we are hitting the
>>> __percpu_counter_compare() slow path too much, then we should be
>>> understanding exactly why that slow path is being hit so hard so
>>> often. I don't see any analysis of the actual per-cpu counter
>>> behaviour and why the slow path is being taken so often....
>> I am thinking of making the following changes:
> No. Please test the change to the per-cpu counters that I suggested:
>
>>> /*
>>>   * Aggregate the per-cpu counter magazines back into the global
>>>   * counter. This avoids the need for repeated compare operations to
>>>   * run the slow path when the majority of the counter value is held
>>>   * in the per-cpu magazines. Folding them back into the global
>>>   * counter means we will continue to hit the fast
>>>   * percpu_counter_read() path until the counter value falls
>>>   * completely within the comparison limit passed to
>>>   * __percpu_counter_compare().
>>>   */
>>> static s64 percpu_counter_aggregate(struct percpu_counter *fbc)
>>> {
>>> 	s64 ret;
>>> 	int cpu;
>>> 	unsigned long flags;
>>>
>>> 	raw_spin_lock_irqsave(&fbc->lock, flags);
>>> 	ret = fbc->count;
>>> 	for_each_online_cpu(cpu) {
>>> 		s32 count = __this_cpu_read(*fbc->counters);
>>>                  ret += count;
>>> 		__this_cpu_sub(*fbc->counters, count)
>>> 	}
>>> 	fbc->count = ret;
>>> 	raw_spin_unlock_irqrestore(&fbc->lock, flags);
>>> 	return ret;
>>> }
>> I don't think that will work as some other CPUs may change the
>> percpu counters values between percpu_counter_aggregate() and
>> __percpu_counter_compare().  To be safe, the precise counter has to
>> be compted whenever the comparison value difference is less than
>> nr_cpus * batch size.
> Well, yes. Why do you think the above function does the same
> function as percpu_counter_sum()? So that the percpu_counter_sum()
> call *inside* __percpu_counter_compare() can be replaced by this
> call. i.e.
>
> 			return -1;
> 	}
> 	/* Need to use precise count */
> -	count = percpu_counter_sum(fbc);
> +	count = percpu_counter_aggregate(fbc);
> 	if (count>  rhs)
> 		return 1;
> 	else if (count<  rhs)
>
> Please think about what I'm saying rather than dismissing it without
> first understanding my suggestions.

I understood what you were saying. However, the per-cpu counter isn't 
protected by the spinlock. Reading it is OK, but writing may cause race 
if that counter is modified by a CPU other than its owning CPU.

The slow performance of percpu_counter_sum() is due to its need to 
access n different (likely cold) cachelines where n is the number of 
CPUs in the system. So the larger the system, the more problematic it 
will be. My main concern about xfs_mod_fdblocks() is that it can 
potentially call percpu_counter_sum() twice which is what I want to 
prevent. It is OK if you don't think that change is necessary. However, 
I will come back if I find more evidence that this can be an issue.

Cheers,
Longman




^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-07 20:00           ` Waiman Long
@ 2015-10-07 23:04             ` Dave Chinner
  2015-10-07 23:20               ` Tejun Heo
  2015-10-08 16:01               ` Waiman Long
  0 siblings, 2 replies; 18+ messages in thread
From: Dave Chinner @ 2015-10-07 23:04 UTC (permalink / raw)
  To: Waiman Long
  Cc: Tejun Heo, Christoph Lameter, linux-kernel, xfs, Scott J Norton,
	Douglas Hatch

On Wed, Oct 07, 2015 at 04:00:42PM -0400, Waiman Long wrote:
> On 10/06/2015 05:30 PM, Dave Chinner wrote:
> >>>/*
> >>>  * Aggregate the per-cpu counter magazines back into the global
> >>>  * counter. This avoids the need for repeated compare operations to
> >>>  * run the slow path when the majority of the counter value is held
> >>>  * in the per-cpu magazines. Folding them back into the global
> >>>  * counter means we will continue to hit the fast
> >>>  * percpu_counter_read() path until the counter value falls
> >>>  * completely within the comparison limit passed to
> >>>  * __percpu_counter_compare().
> >>>  */
> >>>static s64 percpu_counter_aggregate(struct percpu_counter *fbc)
> >>>{
> >>>	s64 ret;
> >>>	int cpu;
> >>>	unsigned long flags;
> >>>
> >>>	raw_spin_lock_irqsave(&fbc->lock, flags);
> >>>	ret = fbc->count;
> >>>	for_each_online_cpu(cpu) {
> >>>		s32 count = __this_cpu_read(*fbc->counters);
> >>>                 ret += count;
> >>>		__this_cpu_sub(*fbc->counters, count)
> >>>	}
> >>>	fbc->count = ret;
> >>>	raw_spin_unlock_irqrestore(&fbc->lock, flags);
> >>>	return ret;
> >>>}
> >>I don't think that will work as some other CPUs may change the
> >>percpu counters values between percpu_counter_aggregate() and
> >>__percpu_counter_compare().  To be safe, the precise counter has to
> >>be compted whenever the comparison value difference is less than
> >>nr_cpus * batch size.
> >Well, yes. Why do you think the above function does the same
> >function as percpu_counter_sum()? So that the percpu_counter_sum()
> >call *inside* __percpu_counter_compare() can be replaced by this
> >call. i.e.
> >
> >			return -1;
> >	}
> >	/* Need to use precise count */
> >-	count = percpu_counter_sum(fbc);
> >+	count = percpu_counter_aggregate(fbc);
> >	if (count>  rhs)
> >		return 1;
> >	else if (count<  rhs)
> >
> >Please think about what I'm saying rather than dismissing it without
> >first understanding my suggestions.
> 
> I understood what you were saying. However, the per-cpu counter
> isn't protected by the spinlock. Reading it is OK, but writing may
> cause race if that counter is modified by a CPU other than its
> owning CPU.

<sigh>

You're still trying to pick apart the code without considering what
we need to acheive.  We don't need to the code to be bullet proof to
test whether this hypothesis is correct or not - we just need
something that is "near-enough" to give us the data point to tell us
where we should focus our efforts. If optimising the counter like
above does not reduce the overhead, then we may have to change XFS.
If it does reduce the overhead, then the XFS code remains unchanged
and we focus on optimising the counter code.

But we *need to test the hypothesis first*.

As it is, the update race you pointed out is easy to solve with
__this_cpu_cmpxchg rather than _this_cpu_sub (similar to mod_state()
in the MM percpu counter stats code, perhaps).

So please test the above change and stop quibbling over details
that just don't matter until we know which way we need to go.

> The slow performance of percpu_counter_sum() is due to its need to
> access n different (likely cold) cachelines where n is the number of
> CPUs in the system. So the larger the system, the more problematic
> it will be.

Welcome to today's lecture titled "Per-cpu Counters 101". :/

Have a think about who you are lecturing(*).  Please don't treat me
as you would university intern who's just learning about
multithreaded programming, because a) it's disrepectful, and b)
you'll jump to the wrong conclusions because you may not immediately
understand what I'm saying or why I'm asking you to do something.

I always start by assuming participants understand the topic being
discussed.  I can quickly tell if a person has deep knowledge of the
topic from their responses and the above "explain the basics"
response is a key indicator.  If you assume that the other person
understands the topic as well or better than you do then you won't
make this mistake and, better yet, we might all learn something in
the ensuing discussion.

Cheers,

Dave.

(*) XFS had custom per-cpu counters because there was no generic
infrastructure in linux for this ten years ago:

commit 8d280b98cfe3c0b69c37d355218975c1c0279bb0
Author: David Chinner <dgc@sgi.com>
Date:   Tue Mar 14 13:13:09 2006 +1100

    [XFS] On machines with more than 8 cpus, when running parallel I/O
    threads, the incore superblock lock becomes the limiting factor for
    buffered write throughput. Make the contended fields in the incore
    superblock use per-cpu counters so that there is no global lock to limit
    scalability.
    
    SGI-PV: 946630
    SGI-Modid: xfs-linux-melb:xfs-kern:25106a
    
    Signed-off-by: David Chinner <dgc@sgi.com>
    Signed-off-by: Nathan Scott <nathans@sgi.com>

-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-07 23:04             ` Dave Chinner
@ 2015-10-07 23:20               ` Tejun Heo
  2015-10-08  1:02                 ` Dave Chinner
  2015-10-08 16:01               ` Waiman Long
  1 sibling, 1 reply; 18+ messages in thread
From: Tejun Heo @ 2015-10-07 23:20 UTC (permalink / raw)
  To: Dave Chinner
  Cc: Waiman Long, Christoph Lameter, linux-kernel, xfs,
	Scott J Norton, Douglas Hatch

Hello, Dave.

On Thu, Oct 08, 2015 at 10:04:42AM +1100, Dave Chinner wrote:
...
> As it is, the update race you pointed out is easy to solve with
> __this_cpu_cmpxchg rather than _this_cpu_sub (similar to mod_state()
> in the MM percpu counter stats code, perhaps).

percpu cmpxchg is no different from sub or any other operations
regarding cross-CPU synchronization.  They're safe iff the operations
are on the local CPU.  They have to be made atomics if they need to be
manipulated from remote CPUs.

That said, while we can't manipulate the percpu counters directly, we
can add a separate global counter to cache sum result from the
previous run which gets automatically invalidated when any percpu
counter overflows.  That should give better and in case of
back-to-back invocations pretty good precision compared to just
returning the global overflow counter.  Interface-wise, that'd be a
lot easier to deal with although I have no idea whether it'd fit this
particular use case or whether this use case even exists.

Thanks.

-- 
tejun

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-07 23:20               ` Tejun Heo
@ 2015-10-08  1:02                 ` Dave Chinner
  2015-10-08  1:09                   ` Tejun Heo
  2015-10-08 16:06                   ` Waiman Long
  0 siblings, 2 replies; 18+ messages in thread
From: Dave Chinner @ 2015-10-08  1:02 UTC (permalink / raw)
  To: Tejun Heo
  Cc: Waiman Long, Christoph Lameter, linux-kernel, xfs,
	Scott J Norton, Douglas Hatch

On Wed, Oct 07, 2015 at 04:20:10PM -0700, Tejun Heo wrote:
> Hello, Dave.
> 
> On Thu, Oct 08, 2015 at 10:04:42AM +1100, Dave Chinner wrote:
> ...
> > As it is, the update race you pointed out is easy to solve with
> > __this_cpu_cmpxchg rather than _this_cpu_sub (similar to mod_state()
> > in the MM percpu counter stats code, perhaps).
> 
> percpu cmpxchg is no different from sub or any other operations
> regarding cross-CPU synchronization.  They're safe iff the operations
> are on the local CPU.  They have to be made atomics if they need to be
> manipulated from remote CPUs.

Again, another trivially solvable problem, but still irrelevant
because we don't have the data that tells us whether changing the
counter behaviour solves the problem....

> That said, while we can't manipulate the percpu counters directly, we
> can add a separate global counter to cache sum result from the
> previous run which gets automatically invalidated when any percpu
> counter overflows.
>
> That should give better and in case of
> back-to-back invocations pretty good precision compared to just
> returning the global overflow counter.  Interface-wise, that'd be a
> lot easier to deal with although I have no idea whether it'd fit this
> particular use case or whether this use case even exists.

No, it doesn't help - it's effectively what Waiman's original patch
did by returning the count from the initial comparison and using
that for ENOSPC detection instead of doing a second comparison...

FWIW, XFS has done an expensive per-cpu counter sum in this ENOSPC
situation since 2006, but in 2007 ENOSPC was wrapped in a mutex to
prevent spinlock contention on the aggregated global counter:

commit 20b642858b6bb413976ff13ae6a35cc596967bab
Author: David Chinner <dgc@sgi.com>
Date:   Sat Feb 10 18:35:09 2007 +1100

    [XFS] Reduction global superblock lock contention near ENOSPC.
    
    The existing per-cpu superblock counter code uses the global superblock
    spin lock when we approach ENOSPC for global synchronisation. On larger
    machines than this code was originally tested on this can still get
    catastrophic spinlock contention due increasing rebalance frequency near
    ENOSPC.
    
    By introducing a sleeping lock that is used to serialise balances and
    modifications near ENOSPC we prevent contention from needlessly from
    wasting the CPU time of potentially hundreds of CPUs.
    
    To reduce the number of balances occuring, we separate the need rebalance
    case from the slow allocate case. Now, a counter running dry will trigger
    a rebalance during which counters are disabled. Any thread that sees a
    disabled counter enters a different path where it waits on the new mutex.
    When it gets the new mutex, it checks if the counter is disabled. If the
    counter is disabled, then we _know_ that we have to use the global counter
    and lock and it is safe to do so immediately. Otherwise, we drop the mutex
    and go back to trying the per-cpu counters which we know were re-enabled.
    
    SGI-PV: 952227
    SGI-Modid: xfs-linux-melb:xfs-kern:27612a
    
    Signed-off-by: David Chinner <dgc@sgi.com>
    Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
    Signed-off-by: Tim Shimmin <tes@sgi.com>

This is effectively the same symptoms that what we are seeing with
the new "lockless" generic percpu counteri algorithm, which is why
I'm trying to find out if it an issue with the counter
implementation before I do anything else...

FWIW, the first comparison doesn't need to be that precise as it
just changes the batch passed to percpu_counter_add() to get the
value folded back into the global counter immediately near ENOSPC.
This is done so percpu_counter_read() becomes more accurate as
ENOSPC is approached as that is used for monitoring and reporting
(e.g. via vfsstat). If we want to avoid a counter sum, then this
is the comparison we will need to modify in XFS.

However, the second comparison needs to be precise as that's the one
that does the ENOSPC detection. That sum needs to be done after the
counter add that "uses" the space and so there is no avoiding having
an expensive counter sum as we near ENOSPC....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-08  1:02                 ` Dave Chinner
@ 2015-10-08  1:09                   ` Tejun Heo
  2015-10-08 16:06                   ` Waiman Long
  1 sibling, 0 replies; 18+ messages in thread
From: Tejun Heo @ 2015-10-08  1:09 UTC (permalink / raw)
  To: Dave Chinner
  Cc: Waiman Long, Christoph Lameter, linux-kernel, xfs,
	Scott J Norton, Douglas Hatch

Hello, Dave.

On Thu, Oct 08, 2015 at 12:02:18PM +1100, Dave Chinner wrote:
> > percpu cmpxchg is no different from sub or any other operations
> > regarding cross-CPU synchronization.  They're safe iff the operations
> > are on the local CPU.  They have to be made atomics if they need to be
> > manipulated from remote CPUs.
> 
> Again, another trivially solvable problem, but still irrelevant
> because we don't have the data that tells us whether changing the
> counter behaviour solves the problem....

Dude, it isn't trivially solvable.  You either can't do it or have to
pay the overhead during local access to get around it.

> > That said, while we can't manipulate the percpu counters directly, we
> > can add a separate global counter to cache sum result from the
> > previous run which gets automatically invalidated when any percpu
> > counter overflows.
> >
> > That should give better and in case of
> > back-to-back invocations pretty good precision compared to just
> > returning the global overflow counter.  Interface-wise, that'd be a
> > lot easier to deal with although I have no idea whether it'd fit this
> > particular use case or whether this use case even exists.
> 
> No, it doesn't help - it's effectively what Waiman's original patch
> did by returning the count from the initial comparison and using
> that for ENOSPC detection instead of doing a second comparison...

Just chipping in purely from percpu side.  If what Waiman suggested is
something useable, caching the result inside percpu_counter would be a
better interface.  If not, no idea.

Thanks.

-- 
tejun

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-07 23:04             ` Dave Chinner
  2015-10-07 23:20               ` Tejun Heo
@ 2015-10-08 16:01               ` Waiman Long
  1 sibling, 0 replies; 18+ messages in thread
From: Waiman Long @ 2015-10-08 16:01 UTC (permalink / raw)
  To: Dave Chinner
  Cc: Tejun Heo, Christoph Lameter, linux-kernel, xfs, Scott J Norton,
	Douglas Hatch

On 10/07/2015 07:04 PM, Dave Chinner wrote:
> On Wed, Oct 07, 2015 at 04:00:42PM -0400, Waiman Long wrote:
>> On 10/06/2015 05:30 PM, Dave Chinner wrote:
>>>>> /*
>>>>>   * Aggregate the per-cpu counter magazines back into the global
>>>>>   * counter. This avoids the need for repeated compare operations to
>>>>>   * run the slow path when the majority of the counter value is held
>>>>>   * in the per-cpu magazines. Folding them back into the global
>>>>>   * counter means we will continue to hit the fast
>>>>>   * percpu_counter_read() path until the counter value falls
>>>>>   * completely within the comparison limit passed to
>>>>>   * __percpu_counter_compare().
>>>>>   */
>>>>> static s64 percpu_counter_aggregate(struct percpu_counter *fbc)
>>>>> {
>>>>> 	s64 ret;
>>>>> 	int cpu;
>>>>> 	unsigned long flags;
>>>>>
>>>>> 	raw_spin_lock_irqsave(&fbc->lock, flags);
>>>>> 	ret = fbc->count;
>>>>> 	for_each_online_cpu(cpu) {
>>>>> 		s32 count = __this_cpu_read(*fbc->counters);
>>>>>                  ret += count;
>>>>> 		__this_cpu_sub(*fbc->counters, count)
>>>>> 	}
>>>>> 	fbc->count = ret;
>>>>> 	raw_spin_unlock_irqrestore(&fbc->lock, flags);
>>>>> 	return ret;
>>>>> }
>>>> I don't think that will work as some other CPUs may change the
>>>> percpu counters values between percpu_counter_aggregate() and
>>>> __percpu_counter_compare().  To be safe, the precise counter has to
>>>> be compted whenever the comparison value difference is less than
>>>> nr_cpus * batch size.
>>> Well, yes. Why do you think the above function does the same
>>> function as percpu_counter_sum()? So that the percpu_counter_sum()
>>> call *inside* __percpu_counter_compare() can be replaced by this
>>> call. i.e.
>>>
>>> 			return -1;
>>> 	}
>>> 	/* Need to use precise count */
>>> -	count = percpu_counter_sum(fbc);
>>> +	count = percpu_counter_aggregate(fbc);
>>> 	if (count>   rhs)
>>> 		return 1;
>>> 	else if (count<   rhs)
>>>
>>> Please think about what I'm saying rather than dismissing it without
>>> first understanding my suggestions.
>> I understood what you were saying. However, the per-cpu counter
>> isn't protected by the spinlock. Reading it is OK, but writing may
>> cause race if that counter is modified by a CPU other than its
>> owning CPU.
> <sigh>
>
> You're still trying to pick apart the code without considering what
> we need to acheive.  We don't need to the code to be bullet proof to
> test whether this hypothesis is correct or not - we just need
> something that is "near-enough" to give us the data point to tell us
> where we should focus our efforts. If optimising the counter like
> above does not reduce the overhead, then we may have to change XFS.
> If it does reduce the overhead, then the XFS code remains unchanged
> and we focus on optimising the counter code.

What determine if a precise sum is to be computed is the following code:

         if (abs(count - rhs) > (batch * num_online_cpus())) {

So even if we make the global count more accurate using 
percpu_counter_aggregate(), it won't have too much effect in reducing 
the chance where the precise count needs to be calculated. That is why I 
don't bother testing it with the modified code.

Cheers,
Longman


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
  2015-10-08  1:02                 ` Dave Chinner
  2015-10-08  1:09                   ` Tejun Heo
@ 2015-10-08 16:06                   ` Waiman Long
  1 sibling, 0 replies; 18+ messages in thread
From: Waiman Long @ 2015-10-08 16:06 UTC (permalink / raw)
  To: Dave Chinner
  Cc: Tejun Heo, Christoph Lameter, linux-kernel, xfs, Scott J Norton,
	Douglas Hatch

On 10/07/2015 09:02 PM, Dave Chinner wrote:
> On Wed, Oct 07, 2015 at 04:20:10PM -0700, Tejun Heo wrote:
>> Hello, Dave.
>>
>> On Thu, Oct 08, 2015 at 10:04:42AM +1100, Dave Chinner wrote:
>> ...
>>> As it is, the update race you pointed out is easy to solve with
>>> __this_cpu_cmpxchg rather than _this_cpu_sub (similar to mod_state()
>>> in the MM percpu counter stats code, perhaps).
>> percpu cmpxchg is no different from sub or any other operations
>> regarding cross-CPU synchronization.  They're safe iff the operations
>> are on the local CPU.  They have to be made atomics if they need to be
>> manipulated from remote CPUs.
> Again, another trivially solvable problem, but still irrelevant
> because we don't have the data that tells us whether changing the
> counter behaviour solves the problem....
>
>> That said, while we can't manipulate the percpu counters directly, we
>> can add a separate global counter to cache sum result from the
>> previous run which gets automatically invalidated when any percpu
>> counter overflows.
>>
>> That should give better and in case of
>> back-to-back invocations pretty good precision compared to just
>> returning the global overflow counter.  Interface-wise, that'd be a
>> lot easier to deal with although I have no idea whether it'd fit this
>> particular use case or whether this use case even exists.
> No, it doesn't help - it's effectively what Waiman's original patch
> did by returning the count from the initial comparison and using
> that for ENOSPC detection instead of doing a second comparison...
>
> FWIW, XFS has done an expensive per-cpu counter sum in this ENOSPC
> situation since 2006, but in 2007 ENOSPC was wrapped in a mutex to
> prevent spinlock contention on the aggregated global counter:
>
> commit 20b642858b6bb413976ff13ae6a35cc596967bab
> Author: David Chinner<dgc@sgi.com>
> Date:   Sat Feb 10 18:35:09 2007 +1100
>
>      [XFS] Reduction global superblock lock contention near ENOSPC.
>
>      The existing per-cpu superblock counter code uses the global superblock
>      spin lock when we approach ENOSPC for global synchronisation. On larger
>      machines than this code was originally tested on this can still get
>      catastrophic spinlock contention due increasing rebalance frequency near
>      ENOSPC.
>
>      By introducing a sleeping lock that is used to serialise balances and
>      modifications near ENOSPC we prevent contention from needlessly from
>      wasting the CPU time of potentially hundreds of CPUs.
>
>      To reduce the number of balances occuring, we separate the need rebalance
>      case from the slow allocate case. Now, a counter running dry will trigger
>      a rebalance during which counters are disabled. Any thread that sees a
>      disabled counter enters a different path where it waits on the new mutex.
>      When it gets the new mutex, it checks if the counter is disabled. If the
>      counter is disabled, then we _know_ that we have to use the global counter
>      and lock and it is safe to do so immediately. Otherwise, we drop the mutex
>      and go back to trying the per-cpu counters which we know were re-enabled.
>
>      SGI-PV: 952227
>      SGI-Modid: xfs-linux-melb:xfs-kern:27612a
>
>      Signed-off-by: David Chinner<dgc@sgi.com>
>      Signed-off-by: Lachlan McIlroy<lachlan@sgi.com>
>      Signed-off-by: Tim Shimmin<tes@sgi.com>
>
> This is effectively the same symptoms that what we are seeing with
> the new "lockless" generic percpu counteri algorithm, which is why
> I'm trying to find out if it an issue with the counter
> implementation before I do anything else...
>
> FWIW, the first comparison doesn't need to be that precise as it
> just changes the batch passed to percpu_counter_add() to get the
> value folded back into the global counter immediately near ENOSPC.
> This is done so percpu_counter_read() becomes more accurate as
> ENOSPC is approached as that is used for monitoring and reporting
> (e.g. via vfsstat). If we want to avoid a counter sum, then this
> is the comparison we will need to modify in XFS.

That is what I have advocated in the in the inlined patch that I sent 
you in a previous mail. That patch modified the first comparison, but 
leave the 2nd comparison intact. We will still see bad performance near 
ENOSPC, but it will be better than before.

> However, the second comparison needs to be precise as that's the one
> that does the ENOSPC detection. That sum needs to be done after the
> counter add that "uses" the space and so there is no avoiding having
> an expensive counter sum as we near ENOSPC....
>
> Cheers,
>
> Dave.

Cheers,
Longman

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2015-10-08 16:06 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-02 17:29 [PATCH] percpu_counter: return precise count from __percpu_counter_compare() Waiman Long
2015-10-02 18:04 ` kbuild test robot
2015-10-05 23:03   ` Waiman Long
2015-10-02 18:05 ` kbuild test robot
2015-10-02 18:12 ` kbuild test robot
2015-10-02 18:15 ` kbuild test robot
2015-10-02 22:16 ` Dave Chinner
2015-10-05 23:02   ` Waiman Long
2015-10-06  0:25     ` Dave Chinner
2015-10-06 17:33       ` Waiman Long
2015-10-06 21:30         ` Dave Chinner
2015-10-07 20:00           ` Waiman Long
2015-10-07 23:04             ` Dave Chinner
2015-10-07 23:20               ` Tejun Heo
2015-10-08  1:02                 ` Dave Chinner
2015-10-08  1:09                   ` Tejun Heo
2015-10-08 16:06                   ` Waiman Long
2015-10-08 16:01               ` Waiman Long

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).