2.5.68-mm3 with contest
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Andrew Morton
Quoted 2 lines · Con Kolivas
All the io-write based loads were affected.
Yup. Mainly because the large queue increases truncate latencies.
Are there loads that do benefit from large queues? If so, does it make sense to use truncate impact (something like a decaying average of truncate time per interval) to control the size of the queues on the fly?
Comments
Ed Tomlinson
Quoted 5 lines · Ed Tomlinson
Quoted 2 lines · Andrew Morton
Con Kolivas <[email protected]> wrote:
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
All the io-write based loads were affected.
Yup. Mainly because the large queue increases truncate latencies.
Are there loads that do benefit from large queues? If so, does it make sense to use truncate impact (something like a decaying average of truncate time per interval) to control the size of the queues on the fly?
I'll post some more benchmarks, but I have found that loads with lots of IO streams. Those with more than about 1/2 as many IO streams as request slots start to show improvements. I don't think changing the size of the queues on the fly would be any good. They can be made runtime tunable quite easily now, which is a good bad solution.