Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+1\/6\]\s+Extend\s+completions\s+to\s+provide\s+XFS\s+object\s+flush\s+requirements\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+1\/6\]\s+Extend\s+completions\s+to\s+provide\s+XFS\s+object\s+flush\s+requirements\s*$/: 54 ]

Total 54 documents matching your query.

1. [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 14:41:12 +1000; XFS object flushing doesn't quite match existing completion semantics. It mixed exclusive access with completion. That is, we need to mark an object as being flushed before flushing it to disk, and t; /archives/xfs/2008-06/msg00333.html (13,872 bytes)
2. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 03:46:36 -0400; Given that the only API call shared with normal completions is complete() I'd rather make this a primitive of it's own, even if internally implemented as completions. Also please add kerneldoc commen; /archives/xfs/2008-06/msg00345.html (12,403 bytes)
3. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 21:21:33 +1000; Ok, so that involves exactly what? A new header file, a new API name (ideas anyone?) and kerneldoc comments? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx; /archives/xfs/2008-06/msg00354.html (13,354 bytes)
4. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Matthew Wilcox <matthew@xxxxxx>; Date: Thu, 26 Jun 2008 05:26:12 -0600; This sounds like mutex semantics. Why are the existing mutexes not appropriate for your needs? -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you; /archives/xfs/2008-06/msg00355.html (11,631 bytes)
5. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 21:32:09 +1000; Different threads doing wait and complete. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx; /archives/xfs/2008-06/msg00357.html (12,145 bytes)
6. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Matthew Wilcox <matthew@xxxxxx>; Date: Thu, 26 Jun 2008 05:42:42 -0600; Then let's leave it as a semaphore. You can get rid of the sema_t if you like, but I don't think that turning completions into semaphores is a good idea (because it's confusing). -- Intel are signing; /archives/xfs/2008-06/msg00358.html (12,304 bytes)
7. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 22:21:12 +1000; So remind me what the point of the semaphore removal tree is again? As Christoph suggested, I can put this under another API that is implemented using completions. If I have to do that in XFS, so be; /archives/xfs/2008-06/msg00359.html (14,024 bytes)
8. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Matthew Wilcox <matthew@xxxxxx>; Date: Thu, 26 Jun 2008 06:40:09 -0600; To remove the semaphores which don't need to be semaphores any more. You could, yes. But you could just use completions directly ... This is exactly the kind of thing completions were supposed to be; /archives/xfs/2008-06/msg00361.html (13,398 bytes)
9. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 08:49:11 -0400; Please read Dave's introductionary mail. What XFS wants if completions with a little bit extra, so he implemented the little bit extra. This little bit extra is pretty well described in the mail star; /archives/xfs/2008-06/msg00362.html (13,599 bytes)
10. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 23:02:04 +1000; Or shouldn't be semaphores in the first place? Not that I can see. Yes, certainly. But as should be obvious by now completions don't quite fit the bill for XFS - they only work for *synchronisation*; /archives/xfs/2008-06/msg00364.html (13,995 bytes)
11. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 09:07:00 -0400; Yes, probably just a new header with properly documented functions. Thew two non-trivial ones you added should probably not be inlines, btw. flush_lock_init/flush_lock/flush_trylock/flush_done/flush_; /archives/xfs/2008-06/msg00365.html (11,560 bytes)
12. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 23:18:29 +1000; Yeah, they grew a little bigger than expected... Ok, I was thinking along those lines. I'll redo the patch series using that interface tomorrow. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx; /archives/xfs/2008-06/msg00366.html (12,517 bytes)
13. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Daniel Walker <dwalker@xxxxxxxxxx>; Date: Thu, 26 Jun 2008 13:33:25 -0700; I think there is some basis to make the changes that you have here. Specifically this email and thread, http://lkml.org/lkml/2008/4/15/232 However, I don't like how your implementing this as specific; /archives/xfs/2008-06/msg00372.html (12,079 bytes)
14. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 27 Jun 2008 11:52:41 +1000; Agreed - but the extension has to start somewhere. So, do I simply add a "init_completion_count()" that passes a count value for the completion (i.e. replaces init_completion_flush())? Except then wa; /archives/xfs/2008-06/msg00378.html (13,774 bytes)
15. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Matthew Wilcox <matthew@xxxxxx>; Date: Thu, 26 Jun 2008 20:24:07 -0600; You've completely missed the point. The current semaphore code is _more_ efficient than the current completion code. I'm very comfortable having two APIs here, one for completion-like semantics and o; /archives/xfs/2008-06/msg00379.html (11,309 bytes)
16. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Daniel Walker <dwalker@xxxxxxxxxx>; Date: Thu, 26 Jun 2008 20:26:39 -0700; Are you saying you want to keep semaphores? Cause I think that goes against the overall agenda that I've seen, which is complete semaphore removal .. If you have issues with the removal method then w; /archives/xfs/2008-06/msg00381.html (10,383 bytes)
17. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Fri, 27 Jun 2008 05:15:09 -0400; Which overall agenda?; /archives/xfs/2008-06/msg00403.html (10,414 bytes)
18. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Daniel Walker <dwalker@xxxxxxxxxx>; Date: Fri, 27 Jun 2008 07:37:12 -0700; Semaphore removal .. Daniel; /archives/xfs/2008-06/msg00415.html (10,356 bytes)
19. [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 14:41:12 +1000; XFS object flushing doesn't quite match existing completion semantics. It mixed exclusive access with completion. That is, we need to mark an object as being flushed before flushing it to disk, and t; /archives/xfs/2008-06/msg00793.html (13,872 bytes)
20. Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Thu, 26 Jun 2008 03:46:36 -0400; Given that the only API call shared with normal completions is complete() I'd rather make this a primitive of it's own, even if internally implemented as completions. Also please add kerneldoc commen; /archives/xfs/2008-06/msg00805.html (12,403 bytes)

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