On Sun, May 23, 2010 at 07:03:10PM +0300, Avi Kivity wrote: > On 05/23/2010 06:51 PM, Michael S. Tsirkin wrote: >>> >>>> So locked version seems to be faster than unlocked, >>>> and share/unshare not to matter? >>>> >>>> >>> May be due to the processor using the LOCK operation as a hint to >>> reserve the cacheline for a bit. >>> >> Maybe we should use atomics on index then? >> > > This should only be helpful if you access the cacheline several times in > a row. That's not the case in virtio (or here). So why does it help? > I think the problem is that LOCKSHARE and SHARE are not symmetric, so > they can't be directly compared. In what sense are they not symmetric? >> OK, after adding mb in code patch will be sent separately, >> the test works for my workstation. locked is still fastest, >> unshared sometimes shows wins and sometimes loses over shared. >> >> [root@qus19 ~]# ./cachebounce share 0 1 >> CPU 0: share cacheline: 6638521 usec >> CPU 1: share cacheline: 6638478 usec >> > > 66 ns? nice. > >> [root@qus19 ~]# ./cachebounce share 0 2 >> CPU 0: share cacheline: 14529198 usec >> CPU 2: share cacheline: 14529156 usec >> > > 140 ns, not too bad. I hope I'm not misinterpreting the results. > > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
