Date: Wed, 15 Apr 2015 09:33:41 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Jason Low <jason.low2@hp.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Oleg Nesterov <oleg@redhat.com>,
        Mike Galbraith <umgwanakikbuti@gmail.com>,
        Frederic Weisbecker <fweisbec@gmail.com>, Mel Gorman <mgorman@suse.de>,
        Steven Rostedt <rostedt@goodmis.org>,
        Preeti U Murthy <preeti@linux.vnet.ibm.com>, hideaki.kimura@hp.com,
        Aswin Chandramouleeswaran <aswin@hp.com>,
        Scott J Norton <scott.norton@hp.com>
Subject: Re: [PATCH 2/3] sched, timer: Use atomics for thread_group_cputimer
 to improve scalability
Message-ID: <20150415073340.GB13449@gmail.com>
References: <1429052986-9420-1-git-send-email-jason.low2@hp.com>
 <1429052986-9420-3-git-send-email-jason.low2@hp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1429052986-9420-3-git-send-email-jason.low2@hp.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1697
Lines: 66


* Jason Low <jason.low2@hp.com> wrote:

> While running a database workload, we found a scalability issue with itimers.
> 
> Much of the problem was caused by the thread_group_cputimer spinlock.

So I'm fine with the basic principle, but in the hope that maybe 
posix-cpu-timers will grow similar optimizations in the future, it 
would help to have the new data type factored out better, not 
open-coded:

>  struct thread_group_cputimer {
> -	struct task_cputime cputime;
> +	atomic64_t utime;
> +	atomic64_t stime;
> +	atomic64_t sum_exec_runtime;
>  	int running;
> -	raw_spinlock_t lock;
>  };

So after your changes we still have a separate:

struct task_cputime {
        cputime_t utime;
        cputime_t stime;
        unsigned long long sum_exec_runtime;
};

Which then weirdly overlaps with a different structure on a different 
abstraction level:

 struct thread_group_cputimer {
	atomic64_t utime;
	atomic64_t stime;
	atomic64_t sum_exec_runtime;
 	int running;
 };

So I think it would be more obvious what's going on if we introduced 
an atomic task_cputime structure:

 struct task_cputime_atomic {
	atomic64_t utime;
	atomic64_t stime;
	atomic64_t sum_exec_runtime;
 };

and put that into 'struct thread_group_cputimer':

 struct thread_group_cputimer {
	struct task_cputime_atomic cputime_atomic;
  	int running;
 };

Maybe even factor out the main update and reading methods into 
expressively named helper inlines?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/