Message-ID: <47040A97.40409@emc.com>
Date:	Wed, 03 Oct 2007 17:33:11 -0400
From:	Ric Wheeler <ric@....com>
To:	Ric Wheeler <ric@....com>, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org, reiserfs-devel@...r.kernel.org,
	"Feld, Andy" <Feld_Andy@....com>,
	Jens Axboe <jens.axboe@...cle.com>
Subject: Re: batching support for transactions

Andreas Dilger wrote:
> 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.

We will do some testing with this in the next day or so.

>>> 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?

Andy's tested 1, 2, 4, 8, 20 and 40 threads.  Once we review the test
and his patch, we can post the summary data.

>>> 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.

This would also seem to be code that would be good to share between all
of the file systems for their transaction bundling.

>>> 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.

One other technique would be to use async IO, which could push the 
batching of the fsync's up to application space.  For example, send down 
a sequence of "async fsync" requests for a series of files and then poll 
for completion once you have launched them.

ric


-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists