[lkml]   [2010]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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:
>> 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.


 \ /
  Last update: 2010-09-07 11:33    [W:0.094 / U:7.136 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site