Hi Sergei, On Thu, Jun 18, 2015 at 11:04:15AM +0200, Sergei Golubchik wrote: > Hi, Sergey! > > On Jun 17, [email protected] wrote: > > revision-id: 3f0b02351a53e0fcaee8554c2c852fb3da8fe7da > > parent(s): 5d03dd20a4abbfd9777b619dfd51a6927323955a > > committer: Sergey Vojtovich > > branch nick: mariadb > > timestamp: 2015-06-17 18:55:38 +0400 > > message: > > > > MDEV-7952 - clock_gettime() takes 0.24% in OLTP RO ...skip...
> > @@ -2793,9 +2793,12 @@ int fill_schema_processlist(THD* thd, TABLE_LIST* > > tables, COND* cond) > > table->field[4]->store(command_name[tmp->get_command()].str, > > command_name[tmp->get_command()].length, > > cs); > > /* MYSQL_TIME */ > > - ulonglong start_utime= tmp->start_time * HRTIME_RESOLUTION + > > tmp->start_time_sec_part; > > - ulonglong utime= start_utime && start_utime < unow.val > > - ? unow.val - start_utime : 0; > > + ulonglong utime= tmp->start_utime; > > + ulonglong utime_after_query_snapshot= tmp->utime_after_query; > > + if (utime < utime_after_query_snapshot) > > + utime= utime_after_query_snapshot; // COM_SLEEP > > + utime= utime && utime < unow ? unow - utime : 0; > > 1. > Please add an assert here that utime<=unow. It uses > microsecond_interval_timer(), which is supposed to be strictly > increasing (unlike my_hrtime()). Somehow I thought that interval_timer() is based on per-CPU clock. But apparently I was wrong. Nevertheless nothing prevents thread from updating start_utime/utime_after_query after we saved unow. So this assertion is not very valid. > > 2. > You might need to update mysqld_list_processes() too. Right. Thanks, Sergey _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
