Ivan Voras wrote: > Julian Elischer wrote: >> You can get better throughput by using TSC for timing because the geom >> and devstat code does a bit of timing.. Geom can be told to turn off >> it's timing but devstat can't. The 170 ktps is with TSC as timer, >> and geom timing turned off. > > I see. I just ran randomio on a gzero device and with 10 userland > threads (this is a slow 2xquad machine) I get g_up and g_down saturated > fast with ~~ 120 ktps. Randomio uses gettimeofday() for measurements. I've just got 140Ktps from two real Intel X25-M SSDs on ICH10R AHCI controller and single Core2Quad CPU. So at least on synthetic tests it is potentially reachable even with casual hardware, while it completely saturated quad-core CPU. > Hmm, it looks like it could be easy to spawn more g_* threads (and, > barring specific class behaviour, it has a fair chance of working out of > the box) but the incoming queue will need to also be broken up for > greater effect. According to "notes", looks there is a good chance to obtain races, as some places expect only one up and one down thread. -- Alexander MotinReceived on Sun Mar 21 2010 - 13:05:23 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:02 UTC