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: <AANLkTinB56HqMrydqH+w_+wUx8+tHjXTq5Y6NjpAU4u8@mail.gmail.com>
Date:	Tue, 7 Sep 2010 15:14:26 +0300
From:	Pekka Enberg <penberg@...nel.org>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	Ingo Molnar <mingo@...e.hu>, 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

On Tue, Sep 7, 2010 at 1:57 PM, KOSAKI Motohiro
<kosaki.motohiro@...fujitsu.com> wrote:
>> 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.
>
> (offtopic)
>
> Afaik, NetBSD plan to include lua interpreter in kernel. it is optimized embedded environment.
>
> (more offtopic)
>
> in kernel interpreter is needed some concern. 1) restricted stack size (typical userland VM
> often use >100K stack size)  2) restrected memory allocation, especially high order allocation
> often fail. 3) GC often makes unacceptable large lag especially on UP kernel. etc etc
> So, We can't apply rich interpreter (e.g. Dalvik, Parrrot) so easily. I think. personally I prefer
> minimum component.

Yes, we definitely don't want to support memory allocation in the
first stages (if ever). I didn't mean that we should integrate Dalvik
or Parriot but that we should look at their _intermediate code_
("bytecode") as an example what we could design for the kernel.
--
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/