linux-kernel - Re: [PATCH] virtio-blk: set QUEUE_ORDERED

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: <4A977A41.1070101@redhat.com>
Date:	Fri, 28 Aug 2009 09:33:37 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
CC:	Christoph Hellwig <hch@....de>, borntraeger@...ibm.com,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH] virtio-blk: set QUEUE_ORDERED_DRAIN by default

On 08/28/2009 04:15 AM, Rusty Russell wrote:
> On Thu, 27 Aug 2009 08:34:19 pm Avi Kivity wrote:
>    
>> There are two possible semantics to cache=writeback:
>>
>> - simulate a drive with a huge write cache; use fsync() to implement
>> barriers
>> - tell the host that we aren't interested in data integrity, lie to the
>> guest to get best performance
>>      
> Why lie to the guest?  Just say we're not ordered, and don't support barriers.
> Gets even *better* performance since it won't drain the queues.
>    

In that case, honesty is preferable.  It means testing with 
cache=writeback exercises different guest code paths, but that's acceptable.

> Maybe you're thinking of full virtualization where we guest ignorance is
> bliss.  But lying always gets us in trouble later on when other cases come
> up.
>
>    
>> The second semantic is not useful for production, but is very useful for
>> testing out things where you aren't worries about host crashes and
>> you're usually rebooting the guest very often (you can't rely on guest
>> caches, so you want the host to cache).
>>      
> This is not the ideal world; people will do things for performance "in
> production".
>
>    

We found that cache=none is faster than cache=writeback when you're 
really interested in performance (no qcow2).

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

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