Re: disabling group leader perf_event

[Avi Kivity <avi@redhat.com>]

  On 09/06/2010 06:30 PM, Alan Cox wrote:
>
>> For me the requirements are:
>> - turing complete (more than just filters)
> Needs infinite storage and may not terminate

Ow come on.  We can always terminate it by inserting checks and 
unwinding the stack; and obviously we'll limit storage.

>> - easy interface to kernel APIs (like hrtimers)
>> - safe to use by untrusted users
>>
>> The actual language doesn't really matter.
> It does for performance and audit. You don't want a JIT as it murders
> cache performance,

Strangely, everyone uses a jit these days unless they're memory 
constrained.  Yes it costs cache, but an interpreter is still slower.

> which means you want
>
> - no self modification

Right.

> - bounded run time

No, I want the ability to terminate the code at any time and clean up 
any resources used.  We have exactly the same requirements for ordinary 
userspace.

> - bounded memory use
> - trustable behaviour for access

Right.

> and usually minimal side effects since you want to optimise very
> heavily and side effects stop that (which is also why Fortran still kicks
> C's backside for crunching)
>
> Not sure you need/want to do the conversion in kernel.

I prefer bytecode as well.

> I'd have thought a
> sane way to handle it would have been to throw stuff at the kernel in
> some kind of semi-sane byte code that can be interpreted by a noddy
> interpreter but firstly when you get it have the kernel try and run a
> helper to compile it.

So you do want to jit?

-- 
error compiling committee.c: too many arguments to function