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 Motin _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]"
