From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 5CEEF6EC6E; Mon, 12 Jul 2021 15:36:30 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 5CEEF6EC6E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1626093390; bh=RojeRndvUYJ2NdJSbHXJZC77P5yiBnhniDnA0SHAQRI=; h=References:In-Reply-To:Date:To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=qgiksaow6HxdHScOVXI+HDTtBIFymVwZLg91jwoM8sBGSVuhbl3ejX39kV05WAmsX aFbVF9y/UAcbcEPBcea1X5JJPDJB6YPVASdLK26Mc+00mnB9fWUc7gPbkUG+wq1dSp jvRLEcf/OU6lYOWs/cBSCAkr7lojVEkB/czx5a04= Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 7733A6EC55 for ; Mon, 12 Jul 2021 15:27:48 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 7733A6EC55 Received: by mail-ot1-f44.google.com with SMTP id f12-20020a056830204cb029048bcf4c6bd9so18652750otp.8 for ; Mon, 12 Jul 2021 05:27:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0rRxorJbiZoYV457QpJQeRx7rdN2KCT2yh1Gk5DSCmU=; b=f/Q1pFkWwP3TxiTHJC0FNSIFljGsQ5YA27NIK280bWA+N4lIhSsXjFyHXQSIQgDyEg Tyb8whQFgX+ndvU572B4zWw9hQXUTMjzfBQ9RUYfhaul/LhjzbYMxLOtGrOWnpuA6Mmu qr8WcG5VCOhKPNZZWuvEaSdVYYhN8hTKsYOVtBddcR1IVq1j6HhF5nEqTMJwrnrP0i3R ncOVSH4eqK6CUewvU4dBwUaRknft7Nn7LAHpVw5uhBT8bjNVTgwHM1DqYzGMaUjMXUiR 37SrayQSSnwKaKfwqyvskCrIdRktnLPxkrC03cT4XbZtZTs5hMXpi/06ZuIXjXA1ryg/ Hafw== X-Gm-Message-State: AOAM530/iVkbQDH2BlwxZXu1NtVwq2/huBtLZ6qkZrRUvHJSYWxJgIYE OB0IitWg3ClwgefwHRlGUMMxZcoiW9ATAehEd9taOXesviXPpKwe X-Google-Smtp-Source: ABdhPJyjNwSGGpO3wF6L5BDhyRwxH7EL65qptGjjhBLSUJTBojTcPc4NXxaDRT/JmcTQg3ckeMCXU8RS/sIovbtdwTc= X-Received: by 2002:a9d:6194:: with SMTP id g20mr12336848otk.282.1626092865991; Mon, 12 Jul 2021 05:27:45 -0700 (PDT) MIME-Version: 1.0 References: <20210712122532.29086-1-max.kokryashkin@gmail.com> In-Reply-To: <20210712122532.29086-1-max.kokryashkin@gmail.com> Date: Mon, 12 Jul 2021 15:27:35 +0300 Message-ID: To: tarantool-discussions@dev.tarantool.org, imun@tarantool.org, skaplun@tarantool.org, sergos@tarantool.org Content-Type: multipart/alternative; boundary="000000000000a6364405c6ec3fd2" X-Mailman-Approved-At: Mon, 12 Jul 2021 15:36:27 +0300 Subject: Re: [Tarantool-discussions] [RFC] add flamegraphs to lua platform profiler doc X-BeenThere: tarantool-discussions@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Maksim Kokryashkin via Tarantool-discussions Reply-To: Maksim Kokryashkin Errors-To: tarantool-discussions-bounces@dev.tarantool.org Sender: "Tarantool-discussions" --000000000000a6364405c6ec3fd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I forgot to provide github link to branch: https://github.com/tarantool/tarantool/tree/fckxorg/rfc-platform-profiler =D0=BF=D0=BD, 12 =D0=B8=D1=8E=D0=BB. 2021 =D0=B3. =D0=B2 15:25, Maxim Kokry= ashkin : > From: Maxim Kokryashkin > > --- > doc/rfc/781-luajit-platform-profiler.md | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/doc/rfc/781-luajit-platform-profiler.md > b/doc/rfc/781-luajit-platform-profiler.md > index fda3d535b..74132c2d4 100644 > --- a/doc/rfc/781-luajit-platform-profiler.md > +++ b/doc/rfc/781-luajit-platform-profiler.md > @@ -14,6 +14,17 @@ Currently, available options for profiling LuaJIT are > not fine enough to get an > > To get a detailed perspective of platform performance, a more advanced > profiler is needed. The desired profiler must be able to capture both gue= st > and host stacks simultaneously, along with virtual machine states. > > +To get the difference, you can take a look at flamegraphs generated by > pref, jit.p, and PoC for the proposed profiler below. > +### jit.p > +![jit.p](https://i.imgur.com/sDZZDZx.png) > + > +### perf > +![perf](https://i.imgur.com/DlKbFpo.png) > + > +### sysprof > +![sysprof](https://i.imgur.com/Yf80MDE.png) > + > + > ## Detailed design > > The proposed approach is to extend existing profiler embedded into > LuaJIT, so it will be able to capture host stack too. > @@ -69,4 +80,4 @@ Another way to implement such a thing is to make perf t= o > see guest stack. To do > Stack unwinding from outside of the LuaJIT is the problem we didn=E2=80= =99t > manage to solve for today. There are different approaches to do this: > - *Save rsp register value to rbp and preserve rbp.* However, LuaJIT use= s > rbp as a general-purpose register, and it is hard not to break everything > trying to use it only for stack frames. > - *Coordinated work of `jit.p` and perf.* This approach requires > modifying perf the way it will send LuaJIT suspension signal, and after > getting info about the host stack, it will receive information about the > guest stack and join them. This solution is quite possible, but modified > perf doesn't seem like a production-ready solution. > -- *Dwarf unwinding* > \ No newline at end of file > +- *Dwarf unwinding* > -- > 2.32.0 > > --000000000000a6364405c6ec3fd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=D0=BF=D0=BD, 12 =D0=B8=D1=8E=D0=BB. 2021 =D0=B3. =D0=B2 15:25,= Maxim Kokryashkin <max.kok= ryashkin@gmail.com>:
From: Maxim Kokryashkin <m.kokryashkin@tarantool.org>

---
=C2=A0doc/rfc/781-luajit-platform-profiler.md | 13 ++++++++++++-
=C2=A01 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/doc/rfc/781-luajit-platform-profiler.md b/doc/rfc/781-luajit-p= latform-profiler.md
index fda3d535b..74132c2d4 100644
--- a/doc/rfc/781-luajit-platform-profiler.md
+++ b/doc/rfc/781-luajit-platform-profiler.md
@@ -14,6 +14,17 @@ Currently, available options for profiling LuaJIT are no= t fine enough to get an

=C2=A0To get a detailed perspective of platform performance, a more advance= d profiler is needed. The desired profiler must be able to capture both gue= st and host stacks simultaneously, along with virtual machine states.

+To get the difference, you can take a look at flamegraphs generated by pre= f, jit.p, and PoC for the proposed profiler below.
+### jit.p
+![jit.p](https://i.imgur.com/sDZZDZx.png)
+
+### perf
+![perf](https://i.imgur.com/DlKbFpo.png)
+
+### sysprof
+![sysprof](https://i.imgur.com/Yf80MDE.png)
+
+
=C2=A0## Detailed design

=C2=A0The proposed approach is to extend existing profiler embedded into Lu= aJIT, so it will be able to capture host stack too.
@@ -69,4 +80,4 @@ Another way to implement such a thing is to make perf to = see guest stack. To do
=C2=A0Stack unwinding from outside of the LuaJIT is the problem we didn=E2= =80=99t manage to solve for today. There are different approaches to do thi= s:
=C2=A0- *Save rsp register value to rbp and preserve rbp.* However, LuaJIT = uses rbp as a general-purpose register, and it is hard not to break everyth= ing trying to use it only for stack frames.
=C2=A0- *Coordinated work of `jit.p` and perf.* This approach requires modi= fying perf the way it will send LuaJIT suspension signal, and after getting= info about the host stack, it will receive information about the guest sta= ck and join them. This solution is quite possible, but modified perf doesn&= #39;t seem like a production-ready solution.
-- *Dwarf unwinding*
\ No newline at end of file
+- *Dwarf unwinding*
--
2.32.0

--000000000000a6364405c6ec3fd2--