Ok, I've read over Badri's latest patch, and it would seem he
assumes that the kiovec coming into brw_kiovec has buffer_heads of
512bytes (as raw.c would prepare). He then submits the I/O in differing
chunks (eg 2048 + 4096 + 4096 + 2048 for a 2048-aligned buffer).
Correct me if I am wrong (I can't see anything in raw.c that would
change the sizes in the kiovec).
For O_DIRECT, the fallback is s_blocksize, not the hardware
minimum of 512. So the kiovec would be coming into brw_kiovec with a
b_size of 4096 or so. My patch lets b_size be anything between 512 and
s_blocksize.
To work with Badri's code, would not the O_DIRECT path want to
submit a kiovec that is entirely b_size = 512 and let brw_kiovec handle
expanding it to larger sizes? This makes my patch simpler, but I wonder
what issues that presents.
Joel
--"When choosing between two evils, I always like to try the one I've never tried before." - Mae West
http://www.jlbec.org/ jlbec@evilplan.org - 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/