Re: [PATCH] enable/disable profiling via proc/sysctl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Levent Serinol <[email protected]> wrote:
>
> This patch enables controlling kernel profiling through proc/sysctl inferface.
> 
>  With this patch profiling will be available without rebooting the
>  machine (especially for
>  production servers) with some drawbacks of vmalloc(tlb). So, bootime
>  algorithm part is left unchanged for anyone who wishes to use
>  profiling as usual without tlb drawback by rebooting the machine.


> --- include/linux/sysctl.h.org	2005-06-13 16:05:17.000000000 +0300
> +++ include/linux/sysctl.h	2005-06-25 15:05:06.000000000 +0300

Patches should be in `patch -p1' form, please.  See
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt

> +static int prof_on = 0;
> +static int prof_booton = 0;

There's no need to explicitly initialise these.

> +#ifdef CONFIG_SMP
> +static int remove_hash_tables(void)
> +{
> +	int cpu;
> +
> +	smp_mb();
> +	on_each_cpu(profile_nop, NULL, 0, 1);

Why?

> +	for_each_online_cpu(cpu) {
> +		struct page *page;
> +
> +		if (per_cpu(cpu_profile_hits, cpu)[0]) {
> +			page = virt_to_page(per_cpu(cpu_profile_hits, cpu)[0]);
> +			per_cpu(cpu_profile_hits, cpu)[0] = NULL;
> +			__free_page(page);
> +		}
> +		if (per_cpu(cpu_profile_hits, cpu)[1]) {
> +			page = virt_to_page(per_cpu(cpu_profile_hits, cpu)[1]);
> +			per_cpu(cpu_profile_hits, cpu)[1] = NULL;
> +			__free_page(page);
> +		}
> +	}

Can this race against itself?  If two cpus run the sysctl at the same time?
We seem to have lock_kernel() coverage.  It's be nice to do something
firmer.

> +int profile_sysctl_handler(ctl_table *table, int write,
> +	struct file *file, void __user *buffer, size_t *length, loff_t *ppos)
> +{
> +	int err;
> +	struct proc_dir_entry *entry;
> +
> +	if (prof_booton && write) return 0;
> +	err=proc_dointvec(table, write, file, buffer, length, ppos);
> +	if ((err >= 0) && write) {
> +	prof_shift = profile_params[1];
> +	switch(profile_params[0])
> +	{
> +	case 0:
> +		if (prof_on) {

Coding style is all over the place here, as well as in most of the rest of
the patch.


	if (prof_booton && write)
		return 0;
	err = proc_dointvec(table, write, file, buffer, length, ppos);
	if (err >= 0 && write) {
		prof_shift = profile_params[1];
		switch (profile_params[0])
		{
		case 0:
			if (prof_on) {

Every line was changed there...

Also, doing multiple returns per function is unpopular, although the
very-early

	if (foo)
		return <something>;

right at the top of the function is OK.  You can use

	if (err < 0 || !write)
		goto out;

to save a tab stop.

> +		     } 
> +		break;

		} 
		break;

> +	case SCHED_PROFILING || CPU_PROFILING:

eh?  I'm surprised the compiler swallowed that.  I guess it's the same as
`case 1:'.  Looks like a bug though.

> +		if (prof_on) return -1;
> +        	prof_len = (_etext - _stext) >> prof_shift;
> +        	prof_buffer = vmalloc(prof_len*sizeof(atomic_t));
> +		if (!prof_buffer) return(-ENOMEM);
> +		if (create_hash_tables()) {
> +			vfree(prof_buffer);
> +			return -1;
> +			}
> +		prof_on = profile_params[0];
> +		if (!(entry = create_proc_entry("profile", S_IWUSR | S_IRUGO, NULL))) {
> +			remove_hash_tables();
> +			vfree(prof_buffer);
> +			return 0;
> +			}
> +		entry->proc_fops = &proc_profile_operations;
> +		entry->size = (1+prof_len) * sizeof(atomic_t);
> +#ifdef CONFIG_HOTPLUG_CPU
> +		register_cpu_notifier(&profile_cpu_notifier);
> +#endif
> +		profile_discard_flip_buffers();
> +        	memset(prof_buffer, 0, prof_len * sizeof(atomic_t));
> +			switch(prof_on)
> +			{
> +			case SCHED_PROFILING:printk(KERN_INFO
> +				"kernel schedule profiling enabled (shift: %ld)\n",
> +				prof_shift);
> +				break;
> +			case CPU_PROFILING:printk(KERN_INFO
> +				"kernel profiling enabled (shift: %ld)\n",
> +				prof_shift);
> +				break;
> +				} 
> +			break;
> +			}
> +		}
> +	return 0;
> +}

Documentation/CodingStyle is your friend ;)

> --- kernel/sysctl.c.org	2005-06-13 16:05:23.000000000 +0300
> +++ kernel/sysctl.c	2005-06-26 02:06:23.000000000 +0300
> ...
> +extern int profile_params[];

Try to place this declaration in a header.

What locking protects prof_boot_on()?  lock_kernel() won't be sufficient
because we're doing sleeping allocations in here.

I suspect it would be best to whap a semaphore around the whole thing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux