Messages in this thread | | | Date | Mon, 06 Sep 2010 18:20:21 +0300 | From | Avi Kivity <> | Subject | Re: disabling group leader perf_event |
| |
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
| |