Re: [-mm] CPU controller statistics (v5)

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Andrew Morton
Date: Wednesday, June 4, 2008 - 2:44 pm

On Wed, 4 Jun 2008 01:35:15 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:


That is not a changelog.  Please always include a (good) changelog with
each iteration of a patch.

Were all my previous comments addressed?  Most, it seems.


Can we avoid these tests?  By requiring that cgroup_subsys.initialize()
always be non-zero?  It might make sense, and it might not...


The above two almost-identical code sequences should, I suggest, be
broken out into a standalone helper function, which has two
implementations, the CONFIG_CGROUP_SCHED=n version of which is a
do-nothing stub, in the usual fashion.

I suggested this last time.


ick at the code layout.  How about this:

	if (!stat)
		return 0;
	return nsec_to_clock_t(percpu_counter_read(&stat->cpustat[idx]));

?


Please prefer to put a blank line between end-of-locals and
start-of-code.  It does make the code somewhat easier to read.



like that.


Suppose the kmalloc failed?


more icky layout, and what's that comma doing there?

Again, please use a bit of thought rather than blindly whacking in
newlines everywhere.

static void cpu_cgroup_initialize(int early)
{
	int i;
	struct cpu_cgroup_stat *stat;

	if (early)
		return;

	stat = kmalloc(sizeof(struct cpu_cgroup_stat), GFP_KERNEL);
	for (i = 0; i < CPU_CGROUP_STAT_NSTATS; i++)
		percpu_counter_init(&stat->cpustat[i], 0);
	init_task_group.stat = stat;
}

is better, yes?


Also, if this code is likely to be executed with any frequency then the
test of `early' could be inlined:

static inline void cpu_cgroup_initialize(int early)
{
	if (unlikely(!early))
		__cpu_cgroup_initialize();
}

yes?



Which will crash the machine if the kmalloc failed.



c'mon guys, that wasn't a great effort.
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[-mm] CPU controller statistics (v5), Balbir Singh, (Tue Jun 3, 1:05 pm)
Re: [-mm] CPU controller statistics (v5), Andrew Morton, (Wed Jun 4, 2:44 pm)
Re: [-mm] CPU controller statistics (v5), Balbir Singh, (Thu Jun 5, 2:37 am)
Re: [-mm] CPU controller statistics (v5), Paul Menage, (Wed Jun 11, 1:28 am)
Re: [-mm] CPU controller statistics (v5), Paul Menage, (Wed Jun 11, 1:32 am)
Re: [-mm] CPU controller statistics (v5), Balbir Singh, (Wed Jun 11, 1:40 am)