[kernel-xen] kernel-xen-3.11.0-1 in testing repo.

[Steven Haigh]

On 17/09/2013 12:05 PM, Glenn Enright wrote:
> On 09/17/13 13:56, Steven Haigh wrote:
>> On 17/09/13 11:30, Glenn Enright wrote:
>>> Preliminary (very) testing seems to indicate a good boost (using 3.11.1)
>>>
>>> Seeing about a 20% increase on buffered writes, and a small but marked
>>> increase on syncronised writes. Which is nice. Keep in mind this is on
>>> an unloaded host with only a couple of VMs.
>>>
>>> In detail ...
>>>
>>> I'm working on a machine with VMs backed by lvm disk over raid1 (using
>>> budget sata drives), with the following snippet, with and without the
>>> fsync option. The test domU uses the noop scheduler.
>>>
>>> for i in 1 2 3 4 5
>>> do
>>>    dd if=/dev/zero of=speedtest bs=1M count=1024 conv=fsync
>>> done
>>>
>>> 3.10 domO, default behavour, custom domu kernel
>>> using fsync average 58 MB/s, without fsync average 59 MB/s,
>>>
>>> 3.11 domO, default behaviour, 3.11 kernel on domu
>>> using fsync average 58 MB/s (ie the same)
>>>
>>> 3.11 domO, using xen-blkfront.max=128, 3.11 kernel on domU
>>> using fsync average 62 MB/s, without fsync average 68 MB/s
>>
>> This is good to see. I'd actually expect a bit more than that - but
>> either way, its good to see an increase in throughput. What actual
>> drives are these? I use Seagate 1Tb 7200rpm SATA drives in my home test
>> setup - but I haven't done a throughput test on the RAID1 as yet - as it
>> hasn't really been problematic in the past.
>>
>> There is talk around this having a way to automatically do a test and
>> set xen-blkfront.max to an optimal value on initialisation of the DomU
>> blkfront module. As yet, this is only talk - however it would probably
>> be a good step forwards.
>>
>> It may even get to the point where it could be backported into distro
>> kernels - and therefore not require the upgrade to 3.11 on the DomU to
>> take advantage of this - however that would be a job for various distros.
>>
>>
>>
> 
> The drives are pair of WD RE3 250G, nothing special there.
> 
> I managed to get the write result up to about 72MB/s average by tweaking
> the read ahead buffer for the raid1. Thats probably about as good as it
> gets given the host OS gets no more than 78Mb/s average on the same pair.
> 
> As time permits I'll try with some different numbers and test raid6 and
> as well.

For what its worth, I've been updating some of my DomU's to the 3.11.1
kernel as well. Currently defining a backup volume to an eSATA drive via
eSATA caddy. It's a single drive:
	Model Family:     Seagate Barracuda 7200.12
	Device Model:     ST31000524AS
	Serial Number:    6VP9DWVG
	LU WWN Device Id: 5 000c50 03ce3905c
	Firmware Version: JC4B
	User Capacity:    1,000,204,886,016 bytes [1.00 TB]

Results via iostat (cutting the header each time):
# iostat sdg -m 5 10
Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sdg             762.81         0.00        96.50          0        433
sdg             787.25         0.00        98.36          0        439
sdg             737.69         0.00        93.40          0        421
sdg             763.92         0.00        96.67          0        434
sdg             741.56         0.00        93.87          0        422
sdg             732.07         0.00        92.66          0        416
sdg             756.12         0.00        95.70          0        429

This is substantially faster than what I was getting with the stock EL6
kernels. The other good news is that this particular DomU has drives
added/removed via scripts - and I don't get any kernel oops messages now ;)

-- 
Steven Haigh

Email: netwiz at crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.wireless.org.au/pipermail/kernel-xen/attachments/20130922/1ce7b5de/attachment.sig>