[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87fx2y9xdn.fsf@basil.nowhere.org>
Date: Wed, 14 Apr 2010 11:49:56 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Salman <sqazi@...gle.com>
Cc: peterz@...radead.org, mingo@...e.hu, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, svaidy@...ux.vnet.ibm.com,
linux-pm@...ts.linux-foundation.org, arjan@...radead.org,
csadler@...gle.com, ranjitm@...gle.com, kenchen@...gle.com,
dawnchen@...gle.com
Subject: Re: [PATCH 1/3] [kidled]: introduce kidled.
Salman <sqazi@...gle.com> writes:
> +
> +static int proc_stats(struct ctl_table *table, int write,
> + void __user *buffer, size_t *lenp, loff_t *ppos)
> +{
> + int ret;
> + unsigned long stats[3];
> + int cpu = (int)((long)table->extra1);
> + struct ctl_table fake = {};
> +
> + if (write)
> + return -EINVAL;
> +
> + fake.data = stats;
> + fake.maxlen = 3*sizeof(unsigned long);
> +
> + ret = smp_call_function_single(cpu, getstats, &stats, 1);
> + if (ret)
> + return ret;
Haven't read the whole thing, but do any of these stats really
need to execute on the target CPU? They seem to be just readable
fields.
Or does it simply not matter because this proc call is too infrequent?
Anyways global broadcasts are discouraged, there is typically
always someone who feels their RT latency be messed up by them.
-Andi
--
ak@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists