Thanks. Note that the old code (which seems to be a tiny bit faster,
and used less CPU as well) has a significantly higher context switch
rate. At a guess I'd say that it is more efficient at getting userspace
up and running in response to IO completion.
I'd say it's only likely to affect these huge linear IOs. Once you get
into real workloads which are seeking and merging then a bit of latency
here or there would just be soaked up by other system activity.
Ah. The current direct-io.c uses wake_up_process(), not waitqueues.
So the aio version has to wear the waitqueue cost. If you're using the
-mm patch I'd suggest that you convert aio.c to prepare_to_wait/finish_wait.
The waitqueue/wakeup costs on your 8-ways seem to be very high.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/