linux-kernel - Re: [RESEND][PATCH 0/4] Virtual Machine Time Accounting

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]

Message-Id: <200709101910.36923.alistair@devzero.co.uk>
Date:	Mon, 10 Sep 2007 19:10:36 +0100
From:	Alistair John Strachan <alistair@...zero.co.uk>
To:	Laurent Vivier <Laurent.Vivier@...l.net>
Cc:	Avi Kivity <avi@...ranet.com>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND][PATCH 0/4] Virtual Machine Time Accounting

On Monday 10 September 2007 14:08:45 Laurent Vivier wrote:
> Avi Kivity wrote:
> > Ingo Molnar wrote:
> >> * Laurent Vivier <Laurent.Vivier@...l.net> wrote:
> >>> Ingo, please, could you have a look to these patches ?
> >>>
> >>> The aim of these four patches is to introduce Virtual Machine time
> >>> accounting.
> >>>
> >>> [PATCH 1/4] as recent CPUs introduce a third running state, after
> >>> "user" and "system", we need a new field, "guest", in cpustat to
> >>> store the time used by the CPU to run virtual CPU. Modify /proc/stat
> >>> to display this new field.
> >>
> >> the concept certainly looks sane to me.
> >>
> >> The heavy-handed use of #ifdefs uglifies the code to a large degree,
> >> but this is not a fundamental problem: since basically all distros
> >> have KVM enabled (and lguest benefits from this too), could you just
> >> make all this new code unconditional?
> >
> > I imagine the embedded people will complain... perhaps move all the code
> > to a #ifdef section above with a full implementation and a stub
> > implementation.
>
> I'm going to repost patches without #ifdefs for readability.
> Then we could discuss if we should introduce #ifdefs and how.

If you could provide a summary of the size increase from your latest post 
(i.e., size of the kernel before and after) that might lay rest to some 
theoretical complaints.

This doesn't look like enough code to warrant ifdefs.

-- 
Cheers,
Alistair.

137/1 Warrender Park Road, Edinburgh, UK.

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