[00:09:53] *** Quits: lhodev (~Adium@66.90.218.190) (Ping timeout: 256 seconds) [00:23:09] *** Joins: lhodev (~Adium@66-90-218-190.dyn.grandenetworks.net) [00:33:49] *** Joins: lhodev1 (~Adium@66-90-218-190.dyn.grandenetworks.net) [00:35:50] *** Quits: lhodev (~Adium@66-90-218-190.dyn.grandenetworks.net) (Ping timeout: 276 seconds) [01:33:10] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [01:35:07] *** Joins: tomzawadzki (~tomzawadz@192.55.54.39) [02:32:20] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [02:33:59] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [04:16:37] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [04:23:48] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [04:54:24] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [05:02:57] *** Quits: lhodev1 (~Adium@66-90-218-190.dyn.grandenetworks.net) (Ping timeout: 240 seconds) [05:06:27] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [05:17:14] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [05:27:56] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [05:56:50] *** Joins: tzawadzki (~tomzawadz@192.55.54.42) [05:58:53] *** Joins: tzawadzki_ (~tomzawadz@134.134.139.76) [05:58:53] *** Quits: tzawadzki (~tomzawadz@192.55.54.42) (Remote host closed the connection) [05:59:51] *** Quits: tomzawadzki (~tomzawadz@192.55.54.39) (Ping timeout: 240 seconds) [06:13:05] *** Quits: tzawadzki_ (~tomzawadz@134.134.139.76) (Ping timeout: 248 seconds) [06:20:00] *** Joins: tomzawadzki (~tomzawadz@192.55.54.42) [07:09:14] *** Joins: tzawadzki (~tomzawadz@192.55.54.39) [07:09:22] *** Quits: tzawadzki (~tomzawadz@192.55.54.39) (Remote host closed the connection) [07:09:38] *** Joins: tzawadzki (~tomzawadz@192.55.54.39) [07:11:27] *** Quits: tomzawadzki (~tomzawadz@192.55.54.42) (Ping timeout: 240 seconds) [08:39:41] *** Joins: lhodev (~Adium@66-90-218-190.dyn.grandenetworks.net) [08:50:55] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [09:19:56] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [09:57:13] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [10:19:05] *** Quits: tzawadzki (~tomzawadz@192.55.54.39) (Ping timeout: 260 seconds) [10:23:19] peluse: can you re-look at https://review.gerrithub.io/#/c/392983/? [10:26:31] jimharris: I re-ran all of the benchmarks with pstates and cstates and hyperthreading disabled [10:26:43] my results all match the expectations [10:27:35] the main difference is that my base core clock is much lower - but there is a section in the document that shows what impact that is supposed to have and my results match what that is saying [10:27:46] so I think we're good to go on https://review.gerrithub.io/#/c/392978/ [10:35:25] bwalker, sure [10:36:33] bwalker, so just curious, what part of the country did you grow up in? [10:36:43] 30 miles north of here [10:55:29] so I still think that sentence is "funny" but if you're emotionally invested I have no serious problems with it ;) [10:55:46] funny ha ha? [10:56:01] I'll reword it to make it easier to parse if you have a suggestion [10:56:12] but what you suggested didn't have subject/verb agreement [10:57:29] I don't know what sounds funny about it - it's totally understandable to me. But if someone finds it hard to read then it should be rewritten. I just need a suggested alternative [10:59:20] nah, I'm good. just giving you a hard time... if someone else reviews it and thinks its awkward you can do something about it [10:59:35] how about just "SPDK polls devices for completions instead of waiting for interrupts" [11:00:02] that works, me like [11:00:57] (thanks) [11:04:31] just took me three attempts to type 'git checkout' [11:04:36] going to have to alias that I guess [11:05:02] in the year 2018, my shell should just figure out what I'm trying to say [11:05:35] by 2020 it will know what you think... [12:20:18] man starting this year I've decided to 'unsubscribe' to every junk email I get instead of just deleting it or tagging it as junk in Outlook. I must have unsubscribed to 30 things so far this year that I'm certain I never signed up for... [12:26:53] *** Quits: lhodev (~Adium@66-90-218-190.dyn.grandenetworks.net) (Quit: Leaving.) [13:46:08] I never used to get junk mail, but now that my email address is all over open source commit histories and on github I get spammed pretty bad [13:47:08] yeah, its crazy [14:05:03] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [14:23:08] peluse: I have been reviewing the new programmer's guides all day, so I just put some feedback on the review with the template to help people avoid common mistakes I'm seeing. https://review.gerrithub.io/#/c/384118/ [14:36:35] *** Quits: sethhowe (~sethhowe@134.134.139.83) (Remote host closed the connection) [14:42:31] *** Joins: lhodev (~Adium@inet-hqmc02-o.oracle.com) [14:44:32] *** Joins: sethhowe (~sethhowe@134.134.139.83) [14:49:28] bwalker, excellent, thanks!! [14:49:48] just finished the io_channel thing too. Will probably need to re-read again after you address a few things but love it so far! [14:50:05] that one was a real challenge to write [14:50:12] this next release will truly be a turning point for SPDK docs... [14:52:39] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [14:53:23] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [15:04:58] *** Quits: sethhowe (~sethhowe@134.134.139.83) (Remote host closed the connection) [15:06:42] *** Joins: sethhowe (~sethhowe@134.134.139.83) [15:44:50] *** Quits: sethhowe (~sethhowe@134.134.139.83) (Remote host closed the connection) [15:51:25] *** Joins: sethhowe (~sethhowe@134.134.139.83) [15:53:55] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Ping timeout: 260 seconds) [16:54:40] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [16:56:22] storing pointer as cache is write operation [16:56:28] this write cause overhead? [16:57:08] hi Shuhei - it depends - is there a specific case you are looking at? [16:58:23] No. is it possible to add a little explanation? [16:58:36] you do not have to add that to the commit comment. [16:59:07] I would like to know to learn. sorry for bothering you. [16:59:15] are you referring to my spdk_bdev_io mgmt_ch patch? [16:59:21] Yes. [16:59:56] let me explain my microbenchmark first - I think it will help you understand [17:00:41] we have a tool called bdevperf (test/lib/bdev/bdevperf) which can be used to test the performance of bdevs - this utility submits IO directly to the bdev layer (no iSCSI, NVMe-oF, vhost) [17:01:09] we also have a "null" bdev module - this will present block devices which do nothing - not even a memcpy [17:01:15] it just immediately completes the bdev_io [17:01:59] so the microbenchmark runs bdevperf with queue depth 16 to 4 null block devices [17:02:29] currently this can do about 25M IO/s on one core - or one I/O per 40ns (or about 80-100 core clocks) [17:02:40] so the bdev layer is very efficient [17:03:17] storing this additional pointer drops performance to about 24.6M IO/s on my system - so maybe it adds on average 1 more core clock per I/O [17:04:02] with a real block device, like NVMe, the SW overhead per I/O is 300-500ns - so with real workload, this one additional pointer store will not be noticed [17:04:31] is my explanation clear? [17:04:38] Yes, very clear! [17:04:50] thanks a lot. [17:09:54] we recently noticed a big difference in performance between nvme/perf tool (nvme driver with no bdev layer) and bdevperf with nvme - so there have been several patches recently which have reduced the bdev overhead significantly [17:14:03] thank you, so your inline patch is one of them. [17:49:06] *** Quits: lhodev (~Adium@inet-hqmc02-o.oracle.com) (Remote host closed the connection) [17:50:39] *** Joins: lhodev (~Adium@66-90-218-190.dyn.grandenetworks.net) [17:54:41] *** Quits: guerby (~guerby@april/board/guerby) (Remote host closed the connection) [17:54:49] *** Joins: guerby (~guerby@ip165.tetaneutral.net) [17:54:49] *** Quits: guerby (~guerby@ip165.tetaneutral.net) (Changing host) [17:54:49] *** Joins: guerby (~guerby@april/board/guerby) [18:13:43] Hi All, I received the result of build failure from SPDK CI, for example https://review.gerrithub.io/#/c/385180/. How to investigate the cause of and to fix it? [18:15:27] Or should I add not only SPDK Automated Test System but also SPDK CI as reviewers to each patch? [18:23:26] *** Joins: guerby_ (~guerby@ip165.tetaneutral.net) [18:23:29] *** Quits: guerby (~guerby@april/board/guerby) (Remote host closed the connection) [18:25:19] *** Joins: ziyeyang_ (~ziyeyang@134.134.139.72) [18:50:37] *** Quits: guerby_ (~guerby@ip165.tetaneutral.net) (Remote host closed the connection) [18:50:48] *** Joins: guerby_ (~guerby@ip165.tetaneutral.net) [19:20:20] *** Joins: guerby__ (~guerby@ip165.tetaneutral.net) [19:20:28] *** Quits: guerby_ (~guerby@ip165.tetaneutral.net) (Remote host closed the connection) [19:22:48] *** Quits: guerby__ (~guerby@ip165.tetaneutral.net) (Read error: Connection reset by peer) [19:22:48] *** Joins: guerby_ (~guerby@ip165.tetaneutral.net) [19:53:20] *** Joins: guerby__ (~guerby@ip165.tetaneutral.net) [19:53:21] *** Quits: guerby_ (~guerby@ip165.tetaneutral.net) (Remote host closed the connection) [21:09:02] *** Quits: guerby__ (~guerby@ip165.tetaneutral.net) (Read error: Connection reset by peer) [21:09:10] *** Joins: guerby (~guerby@ip165.tetaneutral.net) [21:09:10] *** Quits: guerby (~guerby@ip165.tetaneutral.net) (Changing host) [21:09:10] *** Joins: guerby (~guerby@april/board/guerby) [23:26:26] Shuhei: I believe it's a temporary test that fails on it's own [23:26:43] klateck must be testing something [23:45:33] Hi Dariusz, thank you. OK, I'll stay for now.