Hi, Sergey! On Sep 10, Sergey Vojtovich wrote: > Hi Sergei, > > thanks for looking into this patch. Frankly speaking I find it a bit > questionable too. Below are links that should answer your questions... > What problem do I attempt to solve: > https://lists.launchpad.net/maria-developers/msg06118.html > How do I attempt to solve it: https://mariadb.atlassian.net/browse/MDEV-4956
Yes, I've seen and remember both, but they don't answer my question, which was about specific changes that you've done, not about the goal. But ok, see below. > For every statment we acquire table from table cache and then release table > back > to the cache. That involves update of 3 lists: unused_tables, per-share > used_tables and free_tables. These lists are protected by LOCK_open > (see tc_acquire_table() and tc_release_table()). Why per-share lists are updated under the global mutex? > Every time we update global pointer, corresponding cache lines of > sibling CPUs have to be invalidated. This is causing expensive memory > reads while LOCK_open is held. > > Oracle solved this problem by partitioning table cache, allowing > emulation of something like per-CPU lists. > > We attempted to split LOCK_open logically, and succeeded at everything > but these 3 lists. I attempted lock-free list for free_tables, but TPS > rate didn't improve. How did you do the lock-free list, could you show, please? > What we need is to reduce number of these expensive memory reads, and > there are two solutions: partition these lists or get rid of them. As > we agreed not to partition, I'm trying the latter solution. Well, you can partition the list. With 32 list head pointers. And a thread adding a table only to "this thread's" list. Of course, it's not complete partitioning betwen CPUs, as any thread can remove a table from any list. But at least there won't be one global list head pointer. > Why I find this patch questionable? It reduces LOCK_open wait time by > 30%, to get close to Oracle wait time, we need to reduce wait time by > 90%. We could remove unused_tables as well, but it will be 60% not 90%. Hmm, if you're only interested in optimizing this specific use case - one table, many threads - then yes, may be. But if you have many tables, then modifying per-share lists under the share own mutex is, basically, a must. Regards, Sergei _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
