Tarantool development patches archive
 help / color / mirror / Atom feed
From: Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Igor Munkin <imun@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH luajit 2/2] test: rewrite sysprof test using managed execution
Date: Tue, 5 Dec 2023 15:25:01 +0300	[thread overview]
Message-ID: <ZW8Wnb-7zCk10FZi@root> (raw)
In-Reply-To: <ZW8R6RsVcBntFqu5@tarantool.org>

Hi, Igor!
Thanks for the fixes!
Please, consider my comments below.

On 05.12.23, Igor Munkin wrote:
> Sergey,
> 
> Thanks for your review!
> 
> On 05.12.23, Sergey Kaplun wrote:
> > Hi, Igor!
> > Thanks for the patch!
> > Really awesome improvement for our sysprof testing!
> > Please consider my comments below.
> > 
> > On 03.12.23, Maxim Kokryashkin wrote:

<snipped>

> > > > +/* Sysprof "/dev/null" stream helpers. {{{ */
> > > > +
> > > > +/*
> > > > + * Yep, 8Mb. Tuned in order not to bother the platform with too
> > > > + * often flushes.
> > > > + */
> > 
> > This comment is misleading since there is no any flushes in the writer
> > function.
> 
> Well, it's not about I/O flushes, but rather about sysprof write-buffer
> pressure, isn't it? Hence, 8Mb is needed to make the test omit almost
> all buffer-flush related callbacks.

Ok, got your point. So mention this in the comment instead. And remove
"/dev/null" mentioning.

> 
> > Also, do we need such big buffer? Maybe `PATH_MAX` * 2 (or something
> > like that) should be enough?
> 
> Could you elaborate the reason for such a strange constant, please?

Considering your comment above this isn't relevant no more. Ignore
please.

> 
> > 
> > > > +#define STREAM_BUFFER_SIZE (8 * 1024 * 1024)
> > > > +#define DEVNULL -1
> > 
> > `DEVNULL` name is misleading (like we've actually opened `/dev/null`).
> > Maybe `DUMMY_FD` is better? Also, I suppose we can drop the `fd` field
> > at all. We can just use static structure in this translation unit and
> > compare pointer against it, so there is no need for an additional field
> > fd in the structure itself.
> 
> I see little reasoning in this suggestion: the approach with the
> structure is quite straight-forward and copied from another sysprof test
> implemented in C. Re naming: I prefer to leave it as is.

I don't get why it is straight-forward. This approach with unused fields
is just misleading. In
<test/tarantool-c-tests/misclib-sysprof-capi.test.c> the `fd` field is
used since the "/dev/null" is opened and data written to it.

Also, since we can use custom writer, that test may be updated wo using
`fd` too. But this should be done as a separate refactoring patch.

> 
> In general, your nit is nice, but I believe it should be applied
> for the patch moving <ptrace> tricks to utils library.

I don't see any relations with ptrace here. It's just the usage of
sysprof's C API.

> 
> > 
> > > > +

<snipped>

> > 
> > Typo: s/<lj_fff_res1>/the <lj_fff_res1>/
> > 
> > > > +	 * FIXME: Make this part test agnostic.
> > 
> > Typo: s/test agnostic/test-agnostic/
> > 
> > Nit: TODO looks more valid for me (since it's working).
> > Feel free to ignore.
> 
> Fixed.
> 
> ================================================================================
> 
> diff --git a/test/tarantool-c-tests/gh-8594-sysprof-ffunc-crash.test.c b/test/tarantool-c-tests/gh-8594-sysprof-ffunc-crash.test.c
> index 44421812..036f8141 100644
> --- a/test/tarantool-c-tests/gh-8594-sysprof-ffunc-crash.test.c
> +++ b/test/tarantool-c-tests/gh-8594-sysprof-ffunc-crash.test.c
> @@ -153,8 +153,8 @@ static int tracee(const char *luacode)
>  
>  	/*
>  	 * XXX: The only event to be streamed must be FFUNC at
> -	 * <lj_fff_res1> instruction.
> -	 * FIXME: Make this part test agnostic.
> +	 * the <lj_fff_res1> instruction.
> +	 * TODO: Make this part test agnostic.

Typo: s/test agnostic/test-agnostic/


> 

<snipped>

> > 
> > -- 
> > Best regards,
> > Sergey Kaplun
> 
> -- 
> Best regards,
> IM

-- 
Best regards,
Sergey Kaplun

  reply	other threads:[~2023-12-05 12:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-28 14:53 [Tarantool-patches] [PATCH luajit 0/2] Use ptrace for sysprof tests Igor Munkin via Tarantool-patches
2023-11-28 14:53 ` [Tarantool-patches] [PATCH luajit 1/2] test: disable buffering for the C test engine Igor Munkin via Tarantool-patches
2023-12-03 12:25   ` Maxim Kokryashkin via Tarantool-patches
2023-12-04  9:48     ` Igor Munkin via Tarantool-patches
2023-12-04  8:46   ` Sergey Kaplun via Tarantool-patches
2023-12-04  9:50     ` Igor Munkin via Tarantool-patches
2023-11-28 14:53 ` [Tarantool-patches] [PATCH luajit 2/2] test: rewrite sysprof test using managed execution Igor Munkin via Tarantool-patches
2023-12-03 14:17   ` Maxim Kokryashkin via Tarantool-patches
2023-12-05  8:37     ` Sergey Kaplun via Tarantool-patches
2023-12-05 12:04       ` Igor Munkin via Tarantool-patches
2023-12-05 12:25         ` Sergey Kaplun via Tarantool-patches [this message]
2023-12-05 12:59           ` Igor Munkin via Tarantool-patches
2023-12-05 15:08             ` Sergey Kaplun via Tarantool-patches
2023-12-05 11:34     ` Igor Munkin via Tarantool-patches
2023-12-05 13:23       ` Maxim Kokryashkin via Tarantool-patches
2023-11-28 16:14 ` [Tarantool-patches] [PATCH luajit 0/2] Use ptrace for sysprof tests Sergey Bronnikov via Tarantool-patches
2024-01-10  8:50 ` Igor Munkin via Tarantool-patches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZW8Wnb-7zCk10FZi@root \
    --to=tarantool-patches@dev.tarantool.org \
    --cc=imun@tarantool.org \
    --cc=skaplun@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH luajit 2/2] test: rewrite sysprof test using managed execution' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox