Re: svn commit: r254380 - in head/sys: kern sys
We have a single-writer / multiple-readers lock on *any particular byte* of a vnode. The rangelock code is what keeps track of this, and the locking contention I was reducing was in the rangelock bookkeeping. So, for example, if multiple processes or multiple threads read or write a file somewhat unintelligently (a small file, operations on the whole file, like in blogbench), they will effectively content for the byte 0, right? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254380 - in head/sys: kern sys
On 08/16/13 02:38, Ivan Voras wrote: We have a single-writer / multiple-readers lock on *any particular byte* of a vnode. The rangelock code is what keeps track of this, and the locking contention I was reducing was in the rangelock bookkeeping. So, for example, if multiple processes or multiple threads read or write a file somewhat unintelligently (a small file, operations on the whole file, like in blogbench), they will effectively content for the byte 0, right? There can be multiple reads or one write, so yes there would be contention in that case. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254380 - in head/sys: kern sys
On 15 August 2013 22:19, Colin Percival cperc...@freebsd.org wrote: For workloads with R parallel reads and W parallel writes, this improves the time spent from O((R+W)^2) to O(W*(R+W)); i.e., heavy parallel-read workloads become significantly more scalable. No statistically significant change in buildworld time has been measured, but synthetic tests of parallel 'dd /dev/null' and 'openssl enc /dev/null' with the input file cached yield dramatic (up to 10x) improvement with high (up to 128 processes) levels of parallelism. That's interesting. Have you tried running the blogbench benchmark before after? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254380 - in head/sys: kern sys
On 08/15/13 13:29, Ivan Voras wrote: On 15 August 2013 22:19, Colin Percival cperc...@freebsd.org wrote: For workloads with R parallel reads and W parallel writes, this improves the time spent from O((R+W)^2) to O(W*(R+W)); i.e., heavy parallel-read workloads become significantly more scalable. No statistically significant change in buildworld time has been measured, but synthetic tests of parallel 'dd /dev/null' and 'openssl enc /dev/null' with the input file cached yield dramatic (up to 10x) improvement with high (up to 128 processes) levels of parallelism. That's interesting. Have you tried running the blogbench benchmark before after? No, I wasn't aware that it existed. Given that this change applies only to parallel operations *on the same vnode* and blogbench seems to have traffic randomly spread between many files, I doubt there would be any difference. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254380 - in head/sys: kern sys
On 15 August 2013 22:32, Colin Percival cperc...@freebsd.org wrote: No, I wasn't aware that it existed. Given that this change applies only to parallel operations *on the same vnode* and blogbench seems to have traffic randomly spread between many files, I doubt there would be any difference. Maybe it could help a bit on the directories? Whatever the problem may be (does FreeBSD still have single-writer + multiple readers lock for processes accessing the same vnode?), there is a huge difference in performance with blogbench between FreeBSD and Linux. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254380 - in head/sys: kern sys
On 08/15/13 14:34, Ivan Voras wrote: On 15 August 2013 22:32, Colin Percival cperc...@freebsd.org wrote: No, I wasn't aware that it existed. Given that this change applies only to parallel operations *on the same vnode* and blogbench seems to have traffic randomly spread between many files, I doubt there would be any difference. Maybe it could help a bit on the directories? Whatever the problem may be (does FreeBSD still have single-writer + multiple readers lock for processes accessing the same vnode?), there is a huge difference in performance with blogbench between FreeBSD and Linux. We have a single-writer / multiple-readers lock on *any particular byte* of a vnode. The rangelock code is what keeps track of this, and the locking contention I was reducing was in the rangelock bookkeeping. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
