Laurent Vivier wrote:
Where did CONFIG_GUEST_ACCOUNTING go?
Lost in the sea ...
Actually, I thought this modification is not enough expensive (in time and
space) to justify a CONFIG_*. But if you think so I can add this in
init/Kconfig.
The difference between "convince everyone
Avi Kivity wrote:
> Laurent Vivier wrote:
>> Avi Kivity wrote:
>> [...]
>>
>>> The normal user/system accounting has the same issue, no? Whereever we
>>> happen to land (kernel or user) gets the whole tick.
>>>
>>> So I think it is okay to have the same limitation for guest time.
>>>
>>>
Avi Kivity wrote:
Laurent Vivier wrote:
Avi Kivity wrote:
[...]
The normal user/system accounting has the same issue, no? Whereever we
happen to land (kernel or user) gets the whole tick.
So I think it is okay to have the same limitation for guest time.
So this is how it looks
Laurent Vivier wrote:
Where did CONFIG_GUEST_ACCOUNTING go?
Lost in the sea ...
Actually, I thought this modification is not enough expensive (in time and
space) to justify a CONFIG_*. But if you think so I can add this in
init/Kconfig.
The difference between convince everyone
Laurent Vivier wrote:
So I think it is okay to have the same limitation for guest time.
OK, so we can go back to my first patch.
Who can decide to introduce this into the kernel ?
The sched.c parts are best merged by Ingo, and I can carry the kvm
parts. Alternatively, I can carry
Laurent Vivier wrote:
Avi Kivity wrote:
[...]
The normal user/system accounting has the same issue, no? Whereever we
happen to land (kernel or user) gets the whole tick.
So I think it is okay to have the same limitation for guest time.
So this is how it looks like.
PATCH 1 and 2
Laurent Vivier wrote:
Avi Kivity wrote:
[...]
The normal user/system accounting has the same issue, no? Whereever we
happen to land (kernel or user) gets the whole tick.
So I think it is okay to have the same limitation for guest time.
So this is how it looks like.
PATCH 1 and 2
Laurent Vivier wrote:
So I think it is okay to have the same limitation for guest time.
OK, so we can go back to my first patch.
Who can decide to introduce this into the kernel ?
The sched.c parts are best merged by Ingo, and I can carry the kvm
parts. Alternatively, I can carry
Avi Kivity wrote:
[...]
>
> The normal user/system accounting has the same issue, no? Whereever we
> happen to land (kernel or user) gets the whole tick.
>
> So I think it is okay to have the same limitation for guest time.
>
So this is how it looks like.
PATCH 1 and 2 are always a
Am Freitag, 17. August 2007 schrieb Laurent Vivier:
> > The normal user/system accounting has the same issue, no? Whereever we
> > happen to land (kernel or user) gets the whole tick.
>
> Yes... but perhaps I should rewrite this too ;-)
If you look further, you will see, that this was actually
Avi Kivity wrote:
> Laurent Vivier wrote:
>>>
- remove PATCH 3, and add in task_struct a "ktime vtime" where we
accumulate
guest time (by calling something like guest_enter() and guest_exit() from
the
virtualization engine), and when in account_system_time() we have
Laurent Vivier wrote:
>>
>>> - remove PATCH 3, and add in task_struct a "ktime vtime" where we accumulate
>>> guest time (by calling something like guest_enter() and guest_exit() from
>>> the
>>> virtualization engine), and when in account_system_time() we have cputime >
>>> vtime we
Rusty Russell wrote:
> On Fri, 2007-08-17 at 09:35 +0200, Laurent Vivier wrote:
>> Rusty Russell wrote:
>>> Hi Laurent,
>> Hi Rusty,
>> how are your puppies ?
>
> They're getting a little fat, actually. Too many features ...
>
>> - remove PATCH 3, and add in task_struct a "ktime vtime" where we
On Fri, 2007-08-17 at 09:35 +0200, Laurent Vivier wrote:
> Rusty Russell wrote:
> > Hi Laurent,
>
> Hi Rusty,
> how are your puppies ?
They're getting a little fat, actually. Too many features ...
> - remove PATCH 3, and add in task_struct a "ktime vtime" where we accumulate
> guest time (by
Rusty Russell wrote:
> On Thu, 2007-08-16 at 17:58 +0200, Laurent Vivier wrote:
>> [PATCH 3/3] introduce "account modifiers" mechanism in the kernel allowing a
>> module to modify the collected accounting for a given task. This
>> implementation
>> is based on the "preempt_notifier".
Rusty Russell wrote:
On Thu, 2007-08-16 at 17:58 +0200, Laurent Vivier wrote:
[PATCH 3/3] introduce account modifiers mechanism in the kernel allowing a
module to modify the collected accounting for a given task. This
implementation
is based on the preempt_notifier. account_system_time() and
On Fri, 2007-08-17 at 09:35 +0200, Laurent Vivier wrote:
Rusty Russell wrote:
Hi Laurent,
Hi Rusty,
how are your puppies ?
They're getting a little fat, actually. Too many features ...
- remove PATCH 3, and add in task_struct a ktime vtime where we accumulate
guest time (by calling
Rusty Russell wrote:
On Fri, 2007-08-17 at 09:35 +0200, Laurent Vivier wrote:
Rusty Russell wrote:
Hi Laurent,
Hi Rusty,
how are your puppies ?
They're getting a little fat, actually. Too many features ...
- remove PATCH 3, and add in task_struct a ktime vtime where we accumulate
Laurent Vivier wrote:
- remove PATCH 3, and add in task_struct a ktime vtime where we accumulate
guest time (by calling something like guest_enter() and guest_exit() from
the
virtualization engine), and when in account_system_time() we have cputime
vtime we substrate vtime from
Avi Kivity wrote:
Laurent Vivier wrote:
- remove PATCH 3, and add in task_struct a ktime vtime where we
accumulate
guest time (by calling something like guest_enter() and guest_exit() from
the
virtualization engine), and when in account_system_time() we have cputime
vtime we
Am Freitag, 17. August 2007 schrieb Laurent Vivier:
The normal user/system accounting has the same issue, no? Whereever we
happen to land (kernel or user) gets the whole tick.
Yes... but perhaps I should rewrite this too ;-)
If you look further, you will see, that this was actually
Avi Kivity wrote:
[...]
The normal user/system accounting has the same issue, no? Whereever we
happen to land (kernel or user) gets the whole tick.
So I think it is okay to have the same limitation for guest time.
So this is how it looks like.
PATCH 1 and 2 are always a prerequisite.
On Thu, 2007-08-16 at 17:58 +0200, Laurent Vivier wrote:
> [PATCH 3/3] introduce "account modifiers" mechanism in the kernel allowing a
> module to modify the collected accounting for a given task. This
> implementation
> is based on the "preempt_notifier". "account_system_time()" and
>
[PATCH 3/3] introduce "account modifiers" mechanism in the kernel allowing a
module to modify the collected accounting for a given task. This implementation
is based on the "preempt_notifier". "account_system_time()" and
"account_user_time()" can call functions registered by a module to modify the
[PATCH 3/3] introduce account modifiers mechanism in the kernel allowing a
module to modify the collected accounting for a given task. This implementation
is based on the preempt_notifier. account_system_time() and
account_user_time() can call functions registered by a module to modify the
cputime
On Thu, 2007-08-16 at 17:58 +0200, Laurent Vivier wrote:
[PATCH 3/3] introduce account modifiers mechanism in the kernel allowing a
module to modify the collected accounting for a given task. This
implementation
is based on the preempt_notifier. account_system_time() and
account_user_time()
26 matches
Mail list logo
