On 01/17/2013 01:50 PM, Mark Tinguely wrote: > On 01/17/13 12:11, Brian Foster wrote: >> The stack_switch check currently occurs in __xfs_bmapi_allocate, >> which means the stack switch only occurs when xfs_bmapi_allocate() >> is called in a loop. Pull the check up before the loop in >> xfs_bmapi_write() such that the first iteration of the loop has >> consistent behavior. >> >> Signed-off-by: Brian Foster<bfoster@xxxxxxxxxx> >> --- >> >> I was reading through this code and confused myself over whether the >> stack >> switch ever actually occurs. Eric and Ben pointed out on irc >> (simultaneously, >> I might add) the surrounding loop that I had missed, but it wasn't >> clear whether >> the behavior to enable the stack switch after the first iteration was >> intentional or not. I'm throwing this out there to either fix the >> issue or seek >> out an explanation for the existing behavior. Thanks! >> >> Brian >> ... > > > Might want to read the Sep 2012 OSS archives, for example the below > thread and the spin off threads. > > http://oss.sgi.com/archives/xfs/2012-09/msg00254.html > Thanks for the pointer Mark. I think I follow the gist of the original problem based on your example (e.g., flusher kicks in and gets a perag, a separate xfsalloc worker is started and pends on the perag, meanwhile it has consumed the worker resource that the original flusher ultimately needed to proceed). > My original patch was in xfs_bmapi_write() and it was moved to its > current location. > So that points me to Dave's fix: http://oss.sgi.com/archives/xfs/2012-10/msg00080.html ... where he calls out doing the stack switch from a limited context (via the new flag) and then moving it into xfs_bmapi_allocate(). I can't say I completely understand the solution here, but my specific question and reason for this patch is to understand that for the case where we do switch stacks (and pass XFS_BMAPI_STACK_SWITCH), is it intentional or part of the solution that we don't actually do the switch until the second (and subsequent) iteration of the loop in xfs_bmapi_write()? Brian > You can force the code by restricting to only one allocation worker and > there were 2 xfstests (76? and 139? come to mind) that quickly triggered > the event. > > --Mark. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
