> 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 my patch, I removed bio_list. So, I do all the processing of "bio"
in end_io() function, instead of postpone it to waiter. Do you think
this matters ?
> 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.
Ok !! I still use wake_up_process() for the sync case.
I will try to use waitqueues and see.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:27 EST