linux-ext4 - Re: transaction batching performance & multi-threaded synchronous writers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <20080715075832.GD6239@webber.adilger.int>
Date:	Tue, 15 Jul 2008 01:58:32 -0600
From:	Andreas Dilger <adilger@....com>
To:	Josef Bacik <jbacik@...hat.com>
Cc:	Ric Wheeler <ricwheeler@...il.com>, linux-ext4@...r.kernel.org
Subject: Re: transaction batching performance & multi-threaded synchronous
	writers

On Jul 14, 2008  12:58 -0400, Josef Bacik wrote:
> Perhaps we track the average time a commit takes to occur, and then if
> the current transaction start time is < than the avg commit time we sleep
> and wait for more things to join the transaction, and then we commit.
> How does that idea sound?  Thanks,

The drawback of this approach is that if the thread waits an extra "average
transaction time" for the transaction to commit then this will increase the
average transaction time each time, and it still won't tell you if there
needs to be a wait at all.

What might be more interesting is tracking how many processes had sync
handles on the previous transaction(s), and once that number of processes
have done that work, or the timeout reached, the transaction is committed.

While this might seem like a hack for the particular benchmark, this
will also optimize real-world workloads like mailserver, NFS/fileserver,
http where the number of threads running at one time is generally fixed.

The best way to do that would be to keep a field in the task struct to
track whether a given thread has participated in transaction "T" when
it starts a new handle, and if not then increment the "number of sync
threads on this transaction" counter.

In journal_stop() if t_num_sync_thr >= prev num_sync_thr then
the transaction can be committed earlier, and if not then it does a
wait_event_interruptible_timeout(cur_num_sync_thr >= prev_num_sync_thr, 1).

While the number of sync threads is growing or constant the commits will 
be rapid, and any "slow" threads will block on the next transaction and
increment its num_sync_thr until the thread count stabilizes (i.e. a small
number of transactions at startup).  After that the wait will be exactly
as long as needed for each thread to participate.  If some threads are
too slow, or stop processing then there will be a single sleep and the
next transaction will wait for fewer threads the next time.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

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