lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 14 Apr 2010 08:41:30 -0700
From:	Salman Qazi <sqazi@...gle.com>
To:	Andi Kleen <andi@...stfloor.org>
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.

On Wed, Apr 14, 2010 at 2:49 AM, Andi Kleen <andi@...stfloor.org> wrote:
> 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.

To capture all the quantities for a CPU atomically, they must be read
on the CPU.  Basically, reading them on that CPU prevents them from
changing as we read them.

Also, if the CPU is idle (injected or otherwise), the quantities won't
get updated.

>
> Or does it simply not matter because this proc call is too infrequent?

It should be infrequent.  The idle cycle injector does all the hard
work.  These interfaces are for monitoring.

>
> Anyways global broadcasts are discouraged, there is typically
> always someone who feels their RT latency be messed up by them.


I will look at it one more time to see if there is something else that
can be done.

>
> -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

Powered by Openwall GNU/*/Linux Powered by OpenVZ