Searched hist:254380 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-10.0-release/sys/kern/ | ||
| H A D | kern_rangelock.c | diff 254380 Thu Aug 15 18:33:56 MDT 2013 cperciva Change the queue of locks in kern_rangelock.c from holding lock requests in the order that they arrive, to holding (a) granted write lock requests, followed by (b) granted read lock requests, followed by (c) ungranted requests, in order of arrival. This changes the stopping condition for iterating through granted locks to see if a new request can be granted: When considering a read lock request, we can stop iterating as soon as we see a read lock request, since anything after that point is either a granted read lock request or a request which has not yet been granted. (For write lock requests, we must still compare against all granted lock requests.) 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. Reviewed by: kib |
| /freebsd-10.0-release/sys/sys/ | ||
| H A D | rangelock.h | diff 254380 Thu Aug 15 18:33:56 MDT 2013 cperciva Change the queue of locks in kern_rangelock.c from holding lock requests in the order that they arrive, to holding (a) granted write lock requests, followed by (b) granted read lock requests, followed by (c) ungranted requests, in order of arrival. This changes the stopping condition for iterating through granted locks to see if a new request can be granted: When considering a read lock request, we can stop iterating as soon as we see a read lock request, since anything after that point is either a granted read lock request or a request which has not yet been granted. (For write lock requests, we must still compare against all granted lock requests.) 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. Reviewed by: kib |
Completed in 115 milliseconds