From: Sergey Kaplun <skaplun@tarantool.org> To: Igor Munkin <imun@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH v2 2/2] metrics: add C and Lua API Date: Fri, 4 Sep 2020 08:29:41 +0300 [thread overview] Message-ID: <20200904052941.GA5215@root> (raw) In-Reply-To: <20200903152237.GE18920@tarantool.org> Igor, On 03.09.20, Igor Munkin wrote: > Sergey, > > On 03.09.20, Sergey Kaplun wrote: > > Igor, > > > > Thanks for the review! > > > > <snipped> > > > > > > > This comment relates to all created files: I see no reason to violate > > > LuaJIT code style, so please adjust the sources considering the current > > > practices. > > > > Should I use 2 space indent? > > Yep, but don't forget tabs for 8-space indent (dunno, whether we can > call such indenting "fake quarter tabs"). Well, I'll use fake quarter tabs here :) > > > > > > > > > > Makefile | 2 +- > > > > src/Makefile | 5 ++-- > > > > src/Makefile.dep | 3 ++ > > > > src/lib_init.c | 2 ++ > > > > src/lib_misc.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++ > > > > src/lj_misc_capi.c | 59 ++++++++++++++++++++++++++++++++++++ > > > > src/lmisclib.h | 61 +++++++++++++++++++++++++++++++++++++ > > > > src/luaconf.h | 1 + > > > > 8 files changed, 205 insertions(+), 3 deletions(-) > > > > create mode 100644 src/lib_misc.c > > > > create mode 100644 src/lj_misc_capi.c > > > > create mode 100644 src/lmisclib.h > > > > > > <snipped> > > > > > > Well, I've already mentioned my concerns while discussing offline the > > > first series. Since I see no corresponding changes, I leave them in this > > > reply. > > > > > > User will face precision loss if any counter exceeds 1 << 53. Consider > > > the following example: > > > | $ luajit -e 'print(2^53 == 2^53 + 1)' > > > | true > > > > > > I guess some counters (e.g. gc_freed and gc_allocated) should be cdata > > > 64-bit numbers instead of the Lua (i.e. doubles) ones. Thoughts? > > > > It's interesting point. In the one way this changes really omit > > precision loss of data. But also when we build LuaJIT with > > <-DLUAJIT_DISABLE_FFI> we should return number type instead of cdata > > again. It leads to inconsistent behaviour of one function depends on > > build type. > > Yes, didn't take this fact into account. > > > > > In the other way we can loss maximum ~2^10, IINM: > > | $ luajit -e 'print(2^63 == 2^63 + 1024)' > > | true > > | $ luajit -e 'print(2^63 == 2^63 + 1025)' > > | false > > > > It means that users can't distinguish between values with a 1Kb > > difference. But for so fast growing up <gc_freed> and <gc_allocated> > > (2^63 bytes) value it shouldn't become a very big problem to them. It's > > really rare situation when you need get your metrics so frequent, that > > you fail to allocate/free 1Kb of objects in due time. > > Well, then this fact should be precisely mentioned in the RFC to be > showed to Lua devs. If precision loss doesn't bother users, I'm for the > current way (i.e. Lua numbers) since it makes less pressure on GC. > I'll add this mention to RFC v3. > > > > P.S. We can s/size_t/uint64_t/ to guarantee maximum fields value. > > IIRC they have the same size, don't they? Formally not necessarily. As mentioned at C11 standard (ISO/IEC 9899:2011), 7.20.3 Limits of other integer types: | Its implementation-defined value shall be equal to or greater | in magnitude (absolute value) than the corresponding value given | below, with the same sign. So it is possible that this value is greater than uint64_t in some implementations. And we can loss more than 1Kb here. But we can just use <size_t> for reasons of common sense. > > > > > <snipped> > > > > > > > Why do you mix inline comments with those going prior to the field? > > > Please choose a single way to write comments here. > > > > LuaJIT code style uses inline comments. May I use comments going prior > > to corresponding field? > > I believe we can excuse Mike's brevity in comments and use comments > going prior to the fields. > Good news :) > > > > <snipped> > > > > > + /* > > > > + * Overall number of snap restores (and number of stopped > > > > > > Strictly saying this is not true, since execution can leave the trace > > > without restoring the snapshot (via <lj_vm_exit_interp>). > > > > Is it correct to say that it is equal to amount of guard assertions > > leading to stopping trace executions? > > I guess so, but see no reason for it. Nevertheless feel free to adjust > the comment the way you want. As Sergos mentioned here [1], this comment should be more descriptive for Lua users. I agreed with him -- this metric should be characterized more clearly than just "Overall number of snap restores". > > > > > <snipped> > > > > > > > And last but not least: what about tests? > > Ping? Hope to see them in v3 series. Oh, sorry! Of course I'll add test for this patch in v3. > > > > > > > -- > > > Best regards, > > > IM > > > > -- > > Best regards, > > Sergey Kaplun > > -- > Best regards, > IM [1]: https://lists.tarantool.org/pipermail/tarantool-patches/2020-July/018823.html -- Best regards, Sergey Kaplun
next prev parent reply other threads:[~2020-09-04 5:29 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-26 20:40 [Tarantool-patches] [PATCH v2 0/2] Implement LuaJIT platform metrics Sergey Kaplun 2020-07-26 20:40 ` [Tarantool-patches] [PATCH v2 1/2] core: introduce various " Sergey Kaplun 2020-08-26 14:48 ` Igor Munkin 2020-08-26 15:52 ` Sergey Ostanevich 2020-08-27 18:42 ` Igor Munkin 2020-09-03 12:51 ` Sergey Kaplun 2020-07-26 20:40 ` [Tarantool-patches] [PATCH v2 2/2] metrics: add C and Lua API Sergey Kaplun 2020-08-27 18:25 ` Igor Munkin 2020-09-03 14:44 ` Sergey Kaplun 2020-09-03 15:22 ` Igor Munkin 2020-09-04 5:29 ` Sergey Kaplun [this message] 2020-07-26 20:42 ` [Tarantool-patches] [PATCH v2] rfc: luajit metrics Sergey Kaplun 2020-08-27 19:18 ` Igor Munkin 2020-09-03 12:57 ` Sergey Kaplun
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=20200904052941.GA5215@root \ --to=skaplun@tarantool.org \ --cc=imun@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v2 2/2] metrics: add C and Lua API' \ /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