All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Vivier <Laurent.Vivier@bull.net>
To: Alistair John Strachan <alistair@devzero.co.uk>
Cc: Avi Kivity <avi@qumranet.com>, Ingo Molnar <mingo@elte.hu>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND][PATCH 0/4] Virtual Machine Time Accounting
Date: Tue, 11 Sep 2007 10:06:53 +0200	[thread overview]
Message-ID: <46E64C9D.2000509@bull.net> (raw)
In-Reply-To: <200709101910.36923.alistair@devzero.co.uk>

[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]

Alistair John Strachan wrote:
> On Monday 10 September 2007 14:08:45 Laurent Vivier wrote:
>> Avi Kivity wrote:
>>> Ingo Molnar wrote:
>>>> * Laurent Vivier <Laurent.Vivier@bull.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.

These patches add:

* at data structures level:

- one cputime64_t (8 bytes) per cpu
- two cputime_t (2 * 4 bytes) per signal_struct and one cputime_t per task_struct

* at processing level:

- display and convert one more value in show_stat() (fs/proc/proc_misc.c)
- display and convert two more values in do_task_stat() (fs/proc/array.c)
- manage (copy and add) one more value in __exit_signal() (kernel/exit.c)
- initialize three more fields in copy_signal (kernel/fork.c)
- add a bit test in account_system_time() and if the bit is set call a new
function (46 bytes on x86_64).

Size of stripped kernel before (on x86_64):
vmlinux 7305064 bytes (not stripped 52643888 bytes)
Size of stripped kernel after:
vmlinux 7305064 bytes (not stripped 52677180 bytes)

means 0 bytes added ????

Laurent
-- 
------------- Laurent.Vivier@bull.net  --------------
          "Software is hard" - Donald Knuth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

      reply	other threads:[~2007-09-11  8:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-10 12:02 [RESEND][PATCH 0/4] Virtual Machine Time Accounting Laurent Vivier
2007-09-10 12:07 ` Ingo Molnar
2007-09-10 12:15   ` Laurent Vivier
2007-09-10 12:50   ` Avi Kivity
2007-09-10 13:08     ` Laurent Vivier
2007-09-10 18:10       ` Alistair John Strachan
2007-09-11  8:06         ` Laurent Vivier [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46E64C9D.2000509@bull.net \
    --to=laurent.vivier@bull.net \
    --cc=alistair@devzero.co.uk \
    --cc=avi@qumranet.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.