commit 4193d9163582b05e33aca3392e46649e5c3da8d1 Merge: 9d457c6 8016867 Author: Linus Torvalds Date: Wed Sep 29 14:58:11 2010 -0700 Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfs * 'for-linus' of git://oss.sgi.com/xfs/xfs: xfs: force background CIL push under sustained load commit 9d457c60ba783c709c750b851d07f0ac8af78ce9 Merge: f12f662 9018231 Author: Linus Torvalds Date: Wed Sep 29 14:57:53 2010 -0700 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6: mfd: Fix max8925 irq control bit incorrect setting mfd: Ignore non-GPIO IRQs when setting wm831x IRQ types commit f12f662f29d5801e598c6bb4a71e54b2de218f72 Author: Daniel J Blueman Date: Wed Sep 29 21:01:55 2010 +0100 fix OMAP2 MTD build failure Fix build failure from recent interface change and merge. Tested on OMAP3430. Signed-off-by: Daniel J Blueman Signed-off-by: Linus Torvalds commit 80168676ebfe4af51407d30f336d67f082d45201 Author: Dave Chinner Date: Fri Sep 24 18:13:44 2010 +1000 xfs: force background CIL push under sustained load I have been seeing occasional pauses in transaction throughput up to 30s long under heavy parallel workloads. The only notable thing was that the xfsaild was trying to be active during the pauses, but making no progress. It was running exactly 20 times a second (on the 50ms no-progress backoff), and the number of pushbuf events was constant across this time as well. IOWs, the xfsaild appeared to be stuck on buffers that it could not push out. Further investigation indicated that it was trying to push out inode buffers that were pinned and/or locked. The xfsbufd was also getting woken at the same frequency (by the xfsaild, no doubt) to push out delayed write buffers. The xfsbufd was not making any progress because all the buffers in the delwri queue were pinned. This scan- and-make-no-progress dance went one in the trace for some seconds, before the xfssyncd came along an issued a log force, and then things started going again. However, I noticed something strange about the log force - there were way too many IO's issued. 516 log buffers were written, to be exact. That added up to 129MB of log IO, which got me very interested because it's almost exactly 25% of the size of the log. He delayed logging code is suppose to aggregate the minimum of 25% of the log or 8MB worth of changes before flushing. That's what really puzzled me - why did a log force write 129MB instead of only 8MB? Essentially what has happened is that no CIL pushes had occurred since the previous tail push which cleared out 25% of the log space. That caused all the new transactions to block because there wasn't log space for them, but they kick the xfsaild to push the tail. However, the xfsaild was not making progress because there were buffers it could not lock and flush, and the xfsbufd could not flush them because they were pinned. As a result, both the xfsaild and the xfsbufd could not move the tail of the log forward without the CIL first committing. The cause of the problem was that the background CIL push, which should happen when 8MB of aggregated changes have been committed, is being held off by the concurrent transaction commit load. The background push does a down_write_trylock() which will fail if there is a concurrent transaction commit holding the push lock in read mode. With 8 CPUs all doing transactions as fast as they can, there was enough concurrent transaction commits to hold off the background push until tail-pushing could no longer free log space, and the halt would occur. It should be noted that there is no reason why it would halt at 25% of log space used by a single CIL checkpoint. This bug could definitely violate the "no transaction should be larger than half the log" requirement and hence result in corruption if the system crashed under heavy load. This sort of bug is exactly the reason why delayed logging was tagged as experimental.... The fix is to start blocking background pushes once the threshold has been exceeded. Rework the threshold calculations to keep the amount of log space a CIL checkpoint can use to below that of the AIL push threshold to avoid the problem completely. Signed-off-by: Dave Chinner Reviewed-by: Alex Elder Reviewed-by: Christoph Hellwig commit 90182317a9e383474613aa60e9d61d57bdf17c3e Author: Kevin Liu Date: Wed Sep 8 09:44:36 2010 -0400 mfd: Fix max8925 irq control bit incorrect setting In max8925_irq_sync_unlock(), irq control bit is set at the same time. Zero means enabling irq, and one means disabling irq. The original code is: irq_chg[0] &= irq_data->enable; It should be changed to: irq_chg[0] &= ~irq_data->enable; Otherwise, irq control bit is mess. Signed-off-by: Kevin Liu Signed-off-by: Haojian Zhuang Signed-off-by: Samuel Ortiz commit c9d66d3515bbb0ad8062721487de7ade02d2b936 Author: Mark Brown Date: Mon Aug 16 20:26:51 2010 +0100 mfd: Ignore non-GPIO IRQs when setting wm831x IRQ types The driver was originally tested with an additional patch which made this unneeded but that patch had issuges and got lost on the way to mainline, causing problems when the errors are reported. Signed-off-by: Mark Brown Signed-off-by: Samuel Ortiz Cc: stable@kernel.org