Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+6\/6\]\s+xfs\:\s+convert\s+xfsbufd\s+to\s+use\s+a\s+workqueue\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+6\/6\]\s+xfs\:\s+convert\s+xfsbufd\s+to\s+use\s+a\s+workqueue\s*$/: 4 ]

Total 4 documents matching your query.

1. [PATCH 6/6] xfs: convert xfsbufd to use a workqueue (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 25 Aug 2011 17:17:06 +1000; There is no reason we need a thread per filesystem to do the flushing of the delayed write buffer queue. This can be easily handled by a global concurrency managed workqueue. Convert the delayed writ; /archives/xfs/2011-08/msg00453.html (19,608 bytes)
2. Re: [PATCH 6/6] xfs: convert xfsbufd to use a workqueue (score: 1): Author: Alex Elder <aelder@xxxxxxx>; Date: Thu, 25 Aug 2011 15:57:19 -0500; I point out one bug below. I also question one of the changes and have some suggestions. I'd like to see this updated and get another chance to review the result. -Alex . . . I think this should be d; /archives/xfs/2011-08/msg00461.html (18,502 bytes)
3. Re: [PATCH 6/6] xfs: convert xfsbufd to use a workqueue (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 26 Aug 2011 09:46:56 +1000; The reason it is done there is so we don't need a local variable to store whether we need to queue work. The fact that the worker must then first grab the bt_delwrite_lock before it will do anything; /archives/xfs/2011-08/msg00463.html (18,773 bytes)
4. Re: [PATCH 6/6] xfs: convert xfsbufd to use a workqueue (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 26 Aug 2011 10:18:24 +1000; Actually, I'll re-instate the existing wait semantics here. In looking at this again I realised there is a race condition in the flushing code - if work is already in progress, then the wq flush won'; /archives/xfs/2011-08/msg00466.html (11,638 bytes)

Current List: 1 - 4
Page: [1]