![]() | |||||||||||||
Messages in this thread |
On Mon, 5 Jan 2009 23:28:26 +1100 Nick Piggin <nickpiggin@yahoo.com.au> wrote: > On Monday 05 January 2009 19:43:00 Andrew Morton wrote: > > The individual patches are mostly at > > http://userweb.kernel.org/~akpm/mmotm/broken-out/ > > > > > > mm-remove-the-might_sleep-from-lock_page.patch > > > > Need to think about this. > > Removing this reduces a lot of might_sleep coverage scope. Page > lock isn't contended in a lot of cases. Why would you drop a > good debugging feature? For the reasons described in the changelog, of course. http://userweb.kernel.org/~akpm/mmotm/broken-out/mm-remove-the-might_sleep-from-lock_page.patch > > mm-direct-io-starvation-improvement.patch > > fs-remove-wb_sync_hold.patch > > fs-sync_sb_inodes-fix.patch > > fs-sys_sync-fix.patch > > radix-tree-gang-set-if-tagged-operation.patch > > This one is unneeded because you didn't take the fsync livelock avoidance > patch that makes use of the new function. OK > > make-sure-nobodys-leaking-resources.patch > > releasing-resources-with-children.patch > > Any reason why not to add these upstream? Dunno. Are they valuable? I've never had a report of them triggering, I don't think. > > nr_blockdev_pages-in_interrupt-warning.patch > > Lockdep should catch this, I guess. Yup. I forget why I added it. > > put_bh-debug.patch > > This could just be implemented with a VM_BUG_ON (or FS_BUG_ON) like the > pagecache refcounting. Wouldn't be a bad idea. yup, I guess so. Again, no reports of it triggering in ages. > > add-a-refcount-check-in-dput.patch > > Again, why not an FS_BUG_ON for things like this too? Ditto. | ||||||||||||
| Last update: 2009-01-12 23:11 [from the cache] ©2003-2008 | |||||||||||||