On Oct 03, 2007 06:42 -0400, Ric Wheeler wrote: > >>With 2 threads writing to the same directory, we instantly drop down to > >>234 files/sec. > > > >Is this with HZ=250? > > Yes - I assume that with HZ=1000 the batching would start to work again > since the penalty for batching would only be 1ms which would add a 0.3ms > overhead while waiting for some other thread to join. This is probably the easiest solution, but at the same time using HZ=1000 adds overhead to the server because of extra interrupts, etc. > >It would seem one of the problems is that we shouldn't really be > >scheduling for a fixed 1 jiffie timeout, but rather only until the > >other threads have a chance to run and join the existing transaction. > > This is really very similar to the domain of the IO schedulers - when do > you hold off an IO and/or try to combine it. I was thinking the same. > >my guess would be that yield() doesn't block the first thread long enough > >for the second one to get into the transaction (e.g. on an 2-CPU system > >with 2 threads, yield() will likely do nothing). > > Andy tried playing with yield() and it did not do well. Note this this > server is a dual CPU box, so your intuition is most likely correct. How many threads did you try? > >It makes sense to track not only the time to commit a single synchronous > >transaction, but also the time between sync transactions to decide if > >the initial transaction should be held to allow later ones. > > Yes, that is what I was trying to suggest with the rate. Even if we are > relatively slow, if the IO's are being synched at a low rate, we are > effectively adding a potentially nasty latency for each IO. > > That would give us two measurements to track per IO device - average > commit time and this average IO's/sec rate. That seems very doable. Agreed. > >Alternately, it might be possible to check if a new thread is trying to > >start a sync handle when the previous one was also synchronous and had > >only a single handle in it, then automatically enable the delay in that > >case. > > I am not sure that this avoids the problem with the current defaults at > 250HZ where each wait is sufficient to do 3 fully independent > transactions ;-) I was trying to think if there was some way to non-busy-wait that is less than 1 jiffie. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
