A few comments on direct path reads:
a) normal (not in memory) PQ uses direct path reads
b) starting from version 11, Oracle might choose a direct path read for a full segment scan based on criteria like size (segment shoud be > 5* small table threshold) and number of blocks in the cache (< 50%)

In Oracle 11.2.0.3, Oracle brings the number of IO's in flight kcblsinc() has decided (2 at start), and tries to reap that number 4 times after the io_submit phase. If one of these calls succeeds, there's no wait.
If that doesn't succeed, Oracle registers an 'direct path read' wait, and just tries to reap 1 IO, then redoes the procedure by going through the io_submit phase, kcblsinc to determine if there's a need for a change in # IO's in flight, then tries to reap them all for four times, etc.

So 'direct path read' means IO wait time from the perspective of the foreground process, and has nothing to do with IO latency time.

Oh, if synchronous IO is used for 'direct path read' waits, the reading sequence is: pread64(), begin timing, end timing (so the timing is bogus; I've verified this for 10.2.0.1, 11.2.0.1 and 11.2.0.3)

HP-UX)
MKNOD=mknod
;;
Darwin) MKNOD=”" ## add for MacosX
;;
*)

if [ -z "${MKNOD}" ]
then
cmd=”mkfifo ${PIPE}”
else
cmd=”$MKNOD $PIPE p”
fi

That is about all. Could you include the changes?