On Mon, Oct 20, 2014 at 3:25 PM, Howard Chu <[email protected]> wrote: > Luke Kenneth Casson Leighton wrote: >> >> On Mon, Oct 20, 2014 at 2:34 PM, Howard Chu <[email protected]> wrote: >>> >>> I can probably use taskset or something similar to restrict a process to >>> a >>> particular set of cores. What exactly do you have in mind? >> >> >> keeping the writers and readers proposed test, but onto the same 8 >> cores only, running: > > > Well in the meantime, the 32/32 test finished: > > Writers Run Time CPU % Context > Switches Write Read Run Time > CPU % > Wall User Sys Vol > Invol Wall User Sys > 1 10:01.38 00:09:34.90 00:00:25.80 99 9 > 2040 27160 5877894 10:00.68 05:19:03.44 00:00:35.34 3192 > 2 10:01.38 00:09:15.15 00:02:41.94 119 14397526 > 2955 24012 6150801 10:00.67 05:19:00.96 00:00:38.23 3192 > 4 10:01.34 00:09:06.93 00:02:46.94 118 14246971 > 8545 23795 6067928 10:00.68 05:18:59.65 00:00:39.52 3192 > 8 10:01.49 00:09:04.22 00:02:53.09 119 14011236 > 10850 23589 5961381 10:00.69 05:18:56.82 00:00:42.54 3192 > 16 10:01.64 00:09:07.32 00:02:53.09 119 13787738 > 20049 23670 5966794 10:00.68 05:18:59.13 00:00:40.35 3192 > 32 10:01.78 00:09:04.29 00:02:58.40 120 13205576 > 27847 23337 5959624 10:00.70 05:19:00.54 00:00:39.46 3192 > > The timings on the left are for the writer process; the reader process > is on the right. You were right, the number of writers is largely > irrelevant because they're all waiting most of the time. There's a > huge jump in System CPU time from 1 writer to 2 writers, because with > only 1 writer the mutex is uncontended and essentially zero-cost. As > more writer threads are added, the System CPU time will rise.
by some 15 to 20% or so, from 2 writers going up to 32 writers. which is not unreasonable - nothing like what i saw (CPU usage dropping to 40%, loadavg jumping to over 8x the number of cores). ok... what's the number of writes being carried out in each transaction? the original scenario in which i saw the issue was when there was one (!!). the design at the time was not optimised for batches of reads followed by batches of writes. a single write per transaction would mean quite a lot more mutex usage. l.
