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
| ||
|
Date: Sun, 06 Apr 2008 10:42:17 +0530 From: Balbir Singh <balbir@...ux.vnet.ibm.com> To: Balaji Rao <balajirrao@...il.com> CC: Dhaval Giani <dhaval@...ux.vnet.ibm.com>, linux-kernel@...r.kernel.org, containers@...ts.osdl.org, menage@...gle.com, a.p.zijlstra@...llo.nl, balbir@...ibm.com, Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com> Subject: Re: [RFC][-mm] [1/2] Simple stats for cpu resource controller Balaji Rao wrote: > On Sunday 06 April 2008 02:29:14 am Dhaval Giani wrote: >> On Sun, Apr 06, 2008 at 02:01:52AM +0530, Balaji Rao wrote: >>> On Sunday 06 April 2008 01:10:41 am Dhaval Giani wrote: >>>>> +}; >>>>> + >>>>> +struct cpu_cgroup_stat_cpu { >>>>> + s64 count[CPU_CGROUP_STAT_NSTATS]; >>>> u64? time does not go negative :) >>> Right. But these stats are not only going to measure time. We need the > same >>> variables for measuring other stats as well. I'm not sure if we would >>> encounter scheduler stats that would count negative. >>> >>> Balbir, what do you say ? >> I would prefer to keep the stats logically separate. So something like >> struct cpu_cgroup_stat_cpu { >> u64 time[]; >> s64 some_other_stat; >> } >> and so on. (I am not sure, is there some advantage gained by using >> structs?) Makes the code more maintainable imho. >> > This would break the generic nature of __cpu_cgroup_stat_add. Its not a nice > thing in my opinion. > I prefer keeping stats in the array as Balaji has done, it makes it easier to do batch processing on the stats. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL -- 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