Date:	Wed, 11 Jul 2012 18:23:49 +0900
From:	Namjae Jeon <linkinjeon@...il.com>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	minchan@...nel.org, Wu Fengguang <fengguang.wu@...el.com>,
	Nam-Jae Jeon <namjae.jeon@...sung.com>,
	Amit Sahrawat <a.sahrawat@...sung.com>,
	Namjae Jeon <linkinjeon@...il.com>,
	Amit Sahrawat <amit.sahrawat83@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	"Myklebust, Trond" <Trond.Myklebust@...app.com>,
	"J. Bruce Fields" <bfields@...ldses.org>, Jan Kara <jack@...e.cz>,
	Al Viro <viro@...iv.linux.org.uk>, dchinner@...hat.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Mel Gorman <mgorman@...e.de>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Wanpeng Li <liwp.linux@...il.com>, namhyung@...nel.org
Subject: [RFC] Writeback : Partially set to interval of writeback per device

[RFC] Writeback : Partially set to interval of writeback per device

At present Writeback threads are controlled by forker thread.
There is one FORKER (bdi-default) thread – which is responsible for
creating new flusher thread for the device and waking up the flusher
threads.

Now – FORKER thread and flusher (Writeback) threads – are both
checking the timing interval value from ‘dirty_writeback_interval’
So – if we have a case of reducing writeback interval – every
WRITEBACK I/O will be controlled using the same settings.

USE CASE:
We have a NFS setup -> with an Ethernet line of 100Mbps – while the
USB disk we have connected on the server has a local speed of 25MBps.

Now – if we perform write operation over NFS (from client to server).
First bottleneck is the network – as the data can travel at the
maximum speed of 100Mbps. But, when we check the default write speed
over NFS on USB HDD - it is around 8MB/sec i.e., atleast we expected
it to be near the NETWORK speed.

This was due to the NFS logic:
During Write operation – Initially pages are dirtied on the NFS client
side. After reaching the dirty limit/writeback limit (or in case of
sync)-> data is sent from the NFS client to the NFS server (so again
pages are dirtied at the NFS server). This is all done inside the
COMMIT call from NFS client to NFS server – which is synchronous.

i.e.,  if suppose 100MB of data is dirtied and sent from the client to
server inside a COMMIT call – then it will take minimum 100MB/100Mbps
~ 8-9seconds.

After 100MB data is reached locally -> it will take 100MB/25Mb/sec ~ 4sec
So – a total 12-13sec in all this operation – We makes it to be around
7~8MB/sec.
After all this data is written on the NFS server device- > COMMIT
response is sent to NFS client.

Now – we figured out that we can improve upon this WRITE performance –
by making use of ideal time at the NFS server i.e., while the data is
getting received from the NFS client-> initiate the WRITEBACK at the
NFS server.  Instead of writing after receiving complete data -> we
can write in parallel while the data is received. As Network is busy
in receiving data while the flusher thread is ideal during that time.
This will reduce the overall timings in COMMIT.

As part this we reduced the ‘dirty_writeback_interval’ -> we could see
the jump in performance to 10~11MB/sec.

Now – the problem is if we change ‘dirty_writeback_interval’ it would
impact the entire storage devices connected to the system. While only
one device which is being used for NFS purpose. So – main purpose is
to have WRITEBACK interval to be effective per device.

There could be many scenarios like this – which requires the Writeback
interval to be effective per device.

Let me know the opinion and advice about this approach.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists