On Thu, 12 May 2011 10:35:03 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > > What (user-visible) problem is this patchset solving? > > > > IOW, what is the current behaviour, what is wrong with that behaviour > > and what effects does the patchset have upon that behaviour? > > > > The sole answer from the above is "latency spikes". Anything else? > > > > I think this set has possibility to fix latency spike. > > For example, in previous set, (which has tuning knobs), do a file copy > of 400M file under 400M limit. > == > 1) == hard limit = 400M == > [root@rhel6-test hilow]# time cp ./tmpfile xxx > real 0m7.353s > user 0m0.009s > sys 0m3.280s > > 2) == hard limit 500M/ hi_watermark = 400M == > [root@rhel6-test hilow]# time cp ./tmpfile xxx > > real 0m6.421s > user 0m0.059s > sys 0m2.707s > == > and in both case, memory usage after test was 400M. I'm surprised that reclaim consumed so much CPU. But I guess that's a 200,000 page/sec reclaim rate which sounds high(?) but it's - what - 15,000 CPU clocks per page? I don't recall anyone spending much effort on instrumenting and reducing CPU consumption in reclaim. Presumably there will be no improvement in CPU consumption on uniprocessor kernels or in single-CPU containers. More likely a deterioration. ahem. Copying a 400MB file in a non-containered kernel on this 8GB machine with old, slow CPUs takes 0.64 seconds systime, 0.66 elapsed. Five times less than your machine. Where the heck did all that CPU time go? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>