From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755280Ab0IFUbO (ORCPT ); Mon, 6 Sep 2010 16:31:14 -0400 Received: from mail-iw0-f174.google.com ([209.85.214.174]:58083 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753137Ab0IFUbE convert rfc822-to-8bit (ORCPT ); Mon, 6 Sep 2010 16:31:04 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=skM7FgWLx3smpSVqcIfyRG6t5oAW1OQ/0BNO2lYZqmvFnDZT0aHLVg1RPhL0R4jcev Rc0DS5hRN8JulQKpUrHmU1JZi18LGwtUsUgCYO6hSP4FcTrm01j4cpRP9VlbHqKIW9Vz hDZbBBnchvjkCotMPBoUbaV+l8ty3EmBm6yi0= MIME-Version: 1.0 In-Reply-To: <20100906154737.GA4332@elte.hu> References: <4C84B088.5050003@redhat.com> <1283772256.1930.303.camel@laptop> <4C84D1CE.3070205@redhat.com> <1283774045.1930.341.camel@laptop> <4C84D77B.6040600@redhat.com> <20100906124330.GA22314@elte.hu> <4C84E265.1020402@redhat.com> <20100906125905.GA25414@elte.hu> <4C850147.8010908@redhat.com> <20100906154737.GA4332@elte.hu> Date: Mon, 6 Sep 2010 23:31:03 +0300 X-Google-Sender-Auth: qJ0Gyk8GI_NHhw5bpcQE4euc4q4 Message-ID: Subject: Re: disabling group leader perf_event From: Pekka Enberg To: Ingo Molnar Cc: Avi Kivity , Pekka Enberg , Tom Zanussi , =?ISO-8859-1?Q?Fr=E9d=E9ric_Weisbecker?= , Steven Rostedt , Arnaldo Carvalho de Melo , Peter Zijlstra , linux-perf-users@vger.kernel.org, linux-kernel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ingo, On Mon, Sep 6, 2010 at 6:47 PM, Ingo Molnar wrote: >> The actual language doesn't really matter. > > There are 3 basic categories: > >  1- Most (least abstract) specific code: a block of bytecode in the form >    of a simplified, executable, kernel-checked x86 machine code block - >    this is also the fastest form. [yes, this is actually possible.] > >  2- Least specific (most abstract) code: A subset/sideset of C - as it's >    the most kernel-developer-trustable/debuggable form. > >  3- Everything else little more than a dot on the spectrum between the >    first two points. > > I lean towards #2 - but #1 looks interesting too. #3 is distinctly > uninteresting as it cannot be as fast as #1 and cannot be as convenient > as #2. It's a question where you want to push the complexity of parsing the language and verifying the executed code. I'd image it's easier to evolve an ABI if we use an intermediate form ("bytecode") on the kernel side. Supporting multiple versions of a C-like language is probably going to be painful. 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. I'm guessing this thing is expected to work on all architectures? If that's true, I'd forget about JIT'ing for the time being and write an interpreter first because it's much easier to port. There are techniques in making an interpreter pretty fast too. Google for "inlining interpreter" if you're interested. 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. Pekka