Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+Move\s+vn_iowait\s+earlier\s+in\s+the\s+reclaim\s+path\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+Move\s+vn_iowait\s+earlier\s+in\s+the\s+reclaim\s+path\s*$/: 33 ]

Total 33 documents matching your query.

1. [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: Lachlan McIlroy <lachlan@xxxxxxx>; Date: Tue, 05 Aug 2008 16:43:29 +1000; Currently by the time we get to vn_iowait() in xfs_reclaim() we have already gone through xfs_inactive()/xfs_free() and recycled the inode. Any I/O completions still running (file size updates and un; /archives/xfs/2008-08/msg00082.html (9,388 bytes)
2. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 5 Aug 2008 17:37:11 +1000; xfs_free()? What's that? The linux inode does not get freed until after ->clear_inode completes, hence it is perfectly valid to reference it anywhere in the ->clear_inode path. My bet is that you are; /archives/xfs/2008-08/msg00088.html (12,340 bytes)
3. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 5 Aug 2008 17:44:25 +1000; Oh, I should point out that that xfs_mark_inode_dirty sync looked like this prior to the patch I posted: /* * If the linux inode is valid, mark it dirty. * Used when commiting a dirty inode into a tr; /archives/xfs/2008-08/msg00092.html (11,084 bytes)
4. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: Lachlan McIlroy <lachlan@xxxxxxx>; Date: Tue, 05 Aug 2008 17:52:34 +1000; Dave Chinner wrote: On Tue, Aug 05, 2008 at 04:43:29PM +1000, Lachlan McIlroy wrote: Currently by the time we get to vn_iowait() in xfs_reclaim() we have already gone through xfs_inactive()/xfs_free(; /archives/xfs/2008-08/msg00093.html (11,151 bytes)
5. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 5 Aug 2008 18:42:20 +1000; Ok, so the question has to be why is there I/O still in progress after the truncate is supposed to have already occurred and the vn_iowait() in xfs_itruncate_start() been executed. Something doesn't; /archives/xfs/2008-08/msg00094.html (11,400 bytes)
6. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: Lachlan McIlroy <lachlan@xxxxxxx>; Date: Wed, 06 Aug 2008 12:28:30 +1000; Dave Chinner wrote: On Tue, Aug 05, 2008 at 05:52:34PM +1000, Lachlan McIlroy wrote: Dave Chinner wrote: On Tue, Aug 05, 2008 at 04:43:29PM +1000, Lachlan McIlroy wrote: Currently by the time we get; /archives/xfs/2008-08/msg00102.html (12,494 bytes)
7. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Wed, 6 Aug 2008 15:20:53 +1000; It won't reintroduce that problem because ->clear_inode() is not called on every NFS write operation. How do we have any new *data* I/O at all in progress at this point? That does not explain why we; /archives/xfs/2008-08/msg00113.html (14,092 bytes)
8. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: Lachlan McIlroy <lachlan@xxxxxxx>; Date: Wed, 06 Aug 2008 16:10:53 +1000; Dave Chinner wrote: On Wed, Aug 06, 2008 at 12:28:30PM +1000, Lachlan McIlroy wrote: Dave Chinner wrote: On Tue, Aug 05, 2008 at 05:52:34PM +1000, Lachlan McIlroy wrote: Dave Chinner wrote: On Tue, A; /archives/xfs/2008-08/msg00119.html (18,832 bytes)
9. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Wed, 6 Aug 2008 19:38:44 +1000; Ah, no. The case here is new_size == 0, which will almost never be the case in the ->release call... Then why isn't is being caught by the vn_iowait() in the truncate code????? The iocount is decreme; /archives/xfs/2008-08/msg00123.html (17,528 bytes)
10. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: Lachlan McIlroy <lachlan@xxxxxxx>; Date: Thu, 07 Aug 2008 18:43:02 +1000; Dave Chinner wrote: On Wed, Aug 06, 2008 at 04:10:53PM +1000, Lachlan McIlroy wrote: Dave Chinner wrote: On Wed, Aug 06, 2008 at 12:28:30PM +1000, Lachlan McIlroy wrote: Dave Chinner wrote: On Tue, A; /archives/xfs/2008-08/msg00133.html (20,754 bytes)
11. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: Lachlan McIlroy <lachlan@xxxxxxx>; Date: Fri, 08 Aug 2008 18:32:01 +1000; Lachlan McIlroy wrote: Dave Chinner wrote: On Wed, Aug 06, 2008 at 04:10:53PM +1000, Lachlan McIlroy wrote: Dave Chinner wrote: On Wed, Aug 06, 2008 at 12:28:30PM +1000, Lachlan McIlroy wrote: Dave C; /archives/xfs/2008-08/msg00146.html (28,322 bytes)
12. [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: xx>; Date: Tue, 05 Aug 2008 16:43:29 +1000; Currently by the time we get to vn_iowait() in xfs_reclaim() we have already gone through xfs_inactive()/xfs_free() and recycled the inode. Any I/O completions still running (file size updates and un; /archives/xfs/2008-08/msg00530.html (9,388 bytes)
13. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: oy); Date: Tue, 5 Aug 2008 17:37:11 +1000; xfs_free()? What's that? The linux inode does not get freed until after ->clear_inode completes, hence it is perfectly valid to reference it anywhere in the ->clear_inode path. My bet is that you are; /archives/xfs/2008-08/msg00536.html (12,340 bytes)
14. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: oy); Date: Tue, 5 Aug 2008 17:44:25 +1000; Oh, I should point out that that xfs_mark_inode_dirty sync looked like this prior to the patch I posted: /* * If the linux inode is valid, mark it dirty. * Used when commiting a dirty inode into a tr; /archives/xfs/2008-08/msg00540.html (11,084 bytes)
15. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: xx>; Date: Tue, 05 Aug 2008 17:52:34 +1000; Dave Chinner wrote: On Tue, Aug 05, 2008 at 04:43:29PM +1000, Lachlan McIlroy wrote: Currently by the time we get to vn_iowait() in xfs_reclaim() we have already gone through xfs_inactive()/xfs_free(; /archives/xfs/2008-08/msg00541.html (11,151 bytes)
16. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: xx>; Date: Tue, 5 Aug 2008 18:42:20 +1000; Ok, so the question has to be why is there I/O still in progress after the truncate is supposed to have already occurred and the vn_iowait() in xfs_itruncate_start() been executed. Something doesn't; /archives/xfs/2008-08/msg00542.html (11,400 bytes)
17. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: xx>; Date: Wed, 06 Aug 2008 12:28:30 +1000; Dave Chinner wrote: On Tue, Aug 05, 2008 at 05:52:34PM +1000, Lachlan McIlroy wrote: Dave Chinner wrote: On Tue, Aug 05, 2008 at 04:43:29PM +1000, Lachlan McIlroy wrote: Currently by the time we get; /archives/xfs/2008-08/msg00550.html (12,494 bytes)
18. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: oy); Date: Wed, 6 Aug 2008 15:20:53 +1000; It won't reintroduce that problem because ->clear_inode() is not called on every NFS write operation. How do we have any new *data* I/O at all in progress at this point? That does not explain why we; /archives/xfs/2008-08/msg00561.html (14,092 bytes)
19. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: oy); Date: Wed, 06 Aug 2008 16:10:53 +1000; Dave Chinner wrote: On Wed, Aug 06, 2008 at 12:28:30PM +1000, Lachlan McIlroy wrote: Dave Chinner wrote: On Tue, Aug 05, 2008 at 05:52:34PM +1000, Lachlan McIlroy wrote: Dave Chinner wrote: On Tue, A; /archives/xfs/2008-08/msg00567.html (18,832 bytes)
20. Re: [PATCH] Move vn_iowait() earlier in the reclaim path (score: 1): Author: ma); Date: Wed, 6 Aug 2008 19:38:44 +1000; Ah, no. The case here is new_size == 0, which will almost never be the case in the ->release call... Then why isn't is being caught by the vn_iowait() in the truncate code????? The iocount is decreme; /archives/xfs/2008-08/msg00571.html (17,528 bytes)

Current List: 1 - 20
Page: [1] [2]