Messages in this thread | | | Date | Sun, 19 Mar 2006 13:09:56 +0800 | From | Wu Fengguang <> | Subject | Re: [PATCH 00/23] Adaptive read-ahead V11 |
| |
On Sat, Mar 18, 2006 at 11:10:33PM -0500, Jon Smirl wrote: > > Maybe the user space solution does the trick by using a larger window size? > > > > IMHO, the stock read-ahead is not designed with extremely high concurrency in > > mind. However, 100 streams should not be a problem at all. > > Has anyone checked to see if the readahead logic is working as > expected from sendfile? IO from sendfile is a different type of > context than IO from user space, there could be sendfile specific
AFAIK, sendfile() and read() use the same readahead logic, which handles them equally good. And there is another readaround logic which handles unhinted mmapped reads.
> problems. If window size is the trick, shouldn't sendfile > automatically adapt it's window size? I don't think you can control > the sendfile window size from user space.
For whole file readings, the stock readahead logic by default uses a fixed window size of VM_MAX_READAHEAD=128KB, the adaptive readahead logic uses an adaptive window size with a high limit of VM_MAX_READAHEAD=1024KB.
The VM_MAX_READAHEAD in the kernel is used to init the .ra_pages attribute of block devices, which can later be altered in _runtime_. To set a 512KB window size limit for hda, one can do it in two ways: 1) blockdev --setra 1024 /dev/hda 2) echo 512 > /sys/block/had/queue/read_ahead_kb
Cheers, Wu - 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/
| |