linux-kernel - Re: disabling group leader perf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTikQk0S-mR2Ow2NgdzqAMB0DD05Vd1Th99gNRy8h@mail.gmail.com>
Date:	Mon, 6 Sep 2010 23:31:03 +0300
From:	Pekka Enberg <penberg@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Avi Kivity <avi@...hat.com>, Pekka Enberg <penberg@...helsinki.fi>,
	Tom Zanussi <tzanussi@...il.com>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-perf-users@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: disabling group leader perf_event

Hi Ingo,

On Mon, Sep 6, 2010 at 6:47 PM, Ingo Molnar <mingo@...e.hu> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/