Re: [kvm-devel] [PATCH][RFC] kvm-scheduler integration

[Avi Kivity <avi@qumranet.com>]

Rusty Russell wrote:
> On Mon, 2007-07-09 at 09:39 +0300, Avi Kivity wrote:
>   
>> Rusty Russell wrote:
>>     
>>> I think a "struct preempt_ops *" and a "void *preempt_ops_data" inside
>>> every task struct is a better idea.  Call the config option
>>> PREEMPT_SCHED_HOOKS and now there's nothing kvm-specific about it...
>>>   
>>>       
>> I considered that, but your proposal does not allow a single task to
>> have multiple preemption hooks installed (hookers?!).  Since in general
>> there's no reason to suppose that users would be mutually exclusive, we
>> need to have a struct hlist of these things.  All in all this seemed to
>> indicate that the second user should have the honor of figuring out that
>> stuff.
>>     
>
> No; this is a "I'm doing something magic and need to know before someone
> else takes the CPU".  Almost by definition, you cannot have two of them
> at the same time.  Let someone else try that if and when...
>   

Why can't you have two of them?  Say I'm writing a module to utilize
branch recording to be able to debug a process in reverse (of course
that doesn't really need sched hooks; let's pretend it does).  Why can't
I debug a process that uses kvm?

More importantly, now the two subsystems have to know about each other
so they don't step on each other's toes.

> But having different hooks for different tasks makes a great deal of
> sense.  This hook makes a great deal of sense.
>   

If we make the hooks non-kvm-specific, I'd just add an hlist there.

> But KVM-specific code in the scheduler is just wrong, and I think we all
> know that.
>   

Even if I eradicate all mention of kvm from the patch, it's still kvm
specific.  kvm at least is sensitive to the exact point where we switch
in (it wants interrupts enabled) and it expects certain parameters to
the callbacks.  If $new_abuser needs other conditions or parameters,
which is quite likely IMO as it will most likely have to do with
hardware, then we will need to update the hooks anyway.

Removing 'kvm' from the patch is easy; but I don't like to pretend to
generality where there ain't.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.