Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+4\/6\]\s+Replace\s+inode\s+flush\s+semaphore\s+with\s+a\s+completion\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+4\/6\]\s+Replace\s+inode\s+flush\s+semaphore\s+with\s+a\s+completion\s*$/: 24 ]

Total 24 documents matching your query.

1. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: Daniel Walker <dwalker@xxxxxxxxxx>; Date: Tue, 12 Aug 2008 20:11:17 -0700; I was looking over this lock in XFS .. The iflock/ifunlock seem to be very much like mutexes in most of the calling locations. Where the lock happens at the start, and the unlock happens when the fun; /archives/xfs/2008-08/msg00204.html (9,433 bytes)
2. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Wed, 13 Aug 2008 17:50:57 +1000; Semaphores, not mutexes. The unlock most commonly happens in a different context (i.e. I/O completion). Firstly, sync flushes are rare. Async are common. Right now we have the case where no matter wh; /archives/xfs/2008-08/msg00206.html (11,846 bytes)
3. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: Daniel Walker <dwalker@xxxxxxxxxx>; Date: Wed, 13 Aug 2008 08:34:01 -0700; You wouldn't base the unlock on what iflush does, you would unconditionally unlock. You wouldn't wait for completion of the flush unless the code really needed to wait. Seems like your indicating tha; /archives/xfs/2008-08/msg00221.html (10,690 bytes)
4. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 14 Aug 2008 10:19:38 +1000; It's not really a flush lock at that point - it's a state lock. We've already got one of those, and a set of state flags that it protects. Basically you're suggesting that we keep external state to t; /archives/xfs/2008-08/msg00224.html (11,573 bytes)
5. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: Daniel Walker <dwalker@xxxxxxxxxx>; Date: Wed, 13 Aug 2008 18:34:49 -0700; I'm not suggesting anything concrete at this point, I'm just thinking about it. If you assume that most of the time your doing async flushing, you wouldn't often need to do blocking on the completion; /archives/xfs/2008-08/msg00230.html (9,712 bytes)
6. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 14 Aug 2008 12:30:54 +1000; I don't think that will work, either - the internal completion counter must stay in sync so there must be a wait_for_completion() call for every complete() call. If we make the wait_for_completion(); /archives/xfs/2008-08/msg00231.html (10,839 bytes)
7. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: xx>; Date: Tue, 12 Aug 2008 20:11:17 -0700; I was looking over this lock in XFS .. The iflock/ifunlock seem to be very much like mutexes in most of the calling locations. Where the lock happens at the start, and the unlock happens when the fun; /archives/xfs/2008-08/msg00652.html (9,433 bytes)
8. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: ok); Date: Wed, 13 Aug 2008 17:50:57 +1000; Semaphores, not mutexes. The unlock most commonly happens in a different context (i.e. I/O completion). Firstly, sync flushes are rare. Async are common. Right now we have the case where no matter wh; /archives/xfs/2008-08/msg00654.html (11,846 bytes)
9. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: xx>; Date: Wed, 13 Aug 2008 08:34:01 -0700; You wouldn't base the unlock on what iflush does, you would unconditionally unlock. You wouldn't wait for completion of the flush unless the code really needed to wait. Seems like your indicating tha; /archives/xfs/2008-08/msg00669.html (10,690 bytes)
10. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: xx>; Date: Thu, 14 Aug 2008 10:19:38 +1000; It's not really a flush lock at that point - it's a state lock. We've already got one of those, and a set of state flags that it protects. Basically you're suggesting that we keep external state to t; /archives/xfs/2008-08/msg00672.html (11,573 bytes)
11. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: xx>; Date: Wed, 13 Aug 2008 18:34:49 -0700; I'm not suggesting anything concrete at this point, I'm just thinking about it. If you assume that most of the time your doing async flushing, you wouldn't often need to do blocking on the completion; /archives/xfs/2008-08/msg00678.html (9,712 bytes)
12. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: xx>; Date: Thu, 14 Aug 2008 12:30:54 +1000; I don't think that will work, either - the internal completion counter must stay in sync so there must be a wait_for_completion() call for every complete() call. If we make the wait_for_completion(); /archives/xfs/2008-08/msg00679.html (10,839 bytes)
13. [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author:; Date: Fri, 11 Jul 2008 11:13:48 +1000; Use the new completion flush code to implement the inode flush lock. Removes one of the final users of semaphores in the XFS code base. Version 2: o make flock functions static inlines o use new comp; /archives/xfs/2008-07/msg00171.html (15,906 bytes)
14. [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: xxxxxx>; Date: Fri, 11 Jul 2008 11:13:48 +1000; Use the new completion flush code to implement the inode flush lock. Removes one of the final users of semaphores in the XFS code base. Version 2: o make flock functions static inlines o use new comp; /archives/xfs/2008-07/msg00794.html (15,906 bytes)
15. [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 27 Jun 2008 18:44:42 +1000; Use the new completion flush code to implement the inode flush lock. Removes one of the final users of semaphores in the XFS code base. Version 2: o make flock functions static inlines o use new comp; /archives/xfs/2008-06/msg00396.html (15,920 bytes)
16. [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 27 Jun 2008 18:44:42 +1000; Use the new completion flush code to implement the inode flush lock. Removes one of the final users of semaphores in the XFS code base. Version 2: o make flock functions static inlines o use new comp; /archives/xfs/2008-06/msg00856.html (15,920 bytes)
17. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: Daniel Walker <dwalker@xxxxxxxxxx>; Date: Tue, 12 Aug 2008 20:11:17 -0700; I was looking over this lock in XFS .. The iflock/ifunlock seem to be very much like mutexes in most of the calling locations. Where the lock happens at the start, and the unlock happens when the fun; /archives/xfs/2008-08/msg01100.html (9,655 bytes)
18. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Wed, 13 Aug 2008 17:50:57 +1000; Semaphores, not mutexes. The unlock most commonly happens in a different context (i.e. I/O completion). Firstly, sync flushes are rare. Async are common. Right now we have the case where no matter wh; /archives/xfs/2008-08/msg01102.html (12,060 bytes)
19. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: Daniel Walker <dwalker@xxxxxxxxxx>; Date: Wed, 13 Aug 2008 08:34:01 -0700; You wouldn't base the unlock on what iflush does, you would unconditionally unlock. You wouldn't wait for completion of the flush unless the code really needed to wait. Seems like your indicating tha; /archives/xfs/2008-08/msg01117.html (10,986 bytes)
20. Re: [PATCH 4/6] Replace inode flush semaphore with a completion (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 14 Aug 2008 10:19:38 +1000; It's not really a flush lock at that point - it's a state lock. We've already got one of those, and a set of state flags that it protects. Basically you're suggesting that we keep external state to t; /archives/xfs/2008-08/msg01120.html (11,875 bytes)

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