Messages in this thread | | | Date | Tue, 07 Sep 2010 12:30:26 +0300 | From | Pekka Enberg <> | Subject | Re: disabling group leader perf_event |
| |
Hi Ingo,
On 9/7/10 7:03 AM, Ingo Molnar wrote: > But i'd prefer C code really, as it's really 'abstract data' in the most > generic sense. That's why the trace filter engine started with a subset > of C.
I think it sounds better in principle than what it will be in practice. The OpenGL shadling language the same kind of model where you use an API call to upload C-like code that gets parsed. That of course has the unfortunate side-effect that compilation error reporting isn't all that user-friendly because you have to query for errors separately.
I think we've seen with ftrace vs. perf that it's easier to write rich, user-friendly interfaces in userspace than in kernel-space.
>> [...] You also probably don't want to put heavy-weight compiler >> optimization passes in the kernel so with an intermediate form, you >> can do much of that in user-space. > > The question of what can and cannot be done in the kernel is overrated. > We sure can put a C compiler into the kernel - 10 years down the line we > wont understand what the fuss was all about.
Yeah, I'm not saying we can't do that but it's a big chunk of code that can be potentially exploited.
>> As for the intermediate form, you might want to take a look at Dalvik: >> >> http://www.netmite.com/android/mydroid/dalvik/docs/dalvik-bytecode.html >> >> and probably ParrotVM bytecode too. The thing to avoid is stack-based >> instructions like in Java bytecode because although it's easy to write >> interpreters for them, it makes JIT'ing harder (which needs to convert >> stack-based representation to register-based) and probably doesn't >> lend itself well to stack-constrained kernel code. > > _If_ we pass in any sort of machine code to the kernel (which bytecode > really is), then we should do the right thing and pass in raw x86 > bytecode, and verify it in the kernel. > > That way the compiler can be kept out of the kernel, and performance of > the thing will be phenomenal from day 1 on. > > For non-x86 in most cases we can use a simple translator that runs > during the verification run - or of course they could have their own > native 'assembly bytecode' verifier and their user-space could compile > to those.
If you'd go for x86 as 'assembly bytecode' which ISA would you pick? 32-bit or 64-bit? I can see problems with both of them:
- The register set that can be encoded with 32-bit ISA is very limited which will force us to spill in memory.
- The 64-bit ISA with REX prefixes is unnecessarily fat.
- Instructions work directly on memory addresses which makes verification harder
- The 32-bit ABI uses stack for argument passing which forces us to verify that operations on stack make sense.
OTOH, if the ABI is that you upload _native code_ on every architecture, then the trade-off makes more sense to me. The downside is that we'd need a separate verifier for each architecture, though.
Pekka
| |