Re: [dm-crypt] dm-crypt flush-to-disk freezes

[Arno Wagner <arno@wagner.name>]

On Wed, Aug 18, 2010 at 01:43:13PM +0200, Milan Broz wrote:
> On 08/17/2010 08:46 PM, Arno Wagner wrote:
> > The set-up is a dm-crypt partition with a Windows XP 
> > VM and the current VMplayer, all with kernel 2.6.34.4
> > from kernel.org and current vmware-tools in the VM.
> 
> Can you be more specific?
> 
> You have direct partition with LUKS and this is mapped
> to vmware directly as disk, right?
> No fs in the middle?

This is VMwarePlayer. I do not think it even supports putting
the OS on a partition. So no, there is ext3 in between and the
VM filesystem Image goes into several 2GB files.
 
Ah, forgot one possibly important detail: This is dm-crypt on top
of md RAID1. 

> Are there other encrypted disks on the same underlying
> device?

No and there is no other didk activity at the time of these 
freezes. 

> Underlying disk is not SSD, right?

No.

> What is the preemption type set in Linux kernel
> (Processor type/Preemption model in kernel config)?

Low latency desktop. But the freezes are too long to 
be CPU related and there is heavy disk activity when 
they happen. Therefore mty conclusion that this is
an emegerncy flush.

> What is the IO scheduler for the underlying device?
> (You can try deadline or cfq with some tuning - this is
> possible to tune online).

Now you are getting into performance optimization. This
is not a performance optimization issue, as there is
no other load on the machine when this happens and
the problem is not something being slow. Anyways, I
just used the default, it has worked well for me so far.

Any recommendations for a different one?

> Probably tuning fs inside vm can help too. If it is
> massive syncing with lot of data waiting for completion,
> it is not good.

Should not. However I do not know what stupidity
can be found in the XP filesystem layer and OS. 
I suspect quit a lot. What I am doing when this 
happens is scrollign thhrough a word document that
has been open for some time or making small edits
with the keyboard. I really see no reasons to flush
a lot of data to disk on this, but it seems it
is done here. 

Then there is also the VMware layer, which has its own
write buffering. Turning it off or on seems to have
no effect on the problem, so for the moment I assume
this is not the source of the problem.
 
> btw I hope that in 2.6.36 we switch to global workqueues
> per cpu for dm-crypt, unfortunately Alasdair is still waiting
> with committing it (patches are ready and I am using it myself).
> (It can help or it can make it worse here. It needs testing.)

I expect I can test this ;-)

Anyways, thanks and I think I will just run the OS unencrypted
for the moment. The data still goes into the encrypted partition
and curiously that does not cause problems. Very strange. 

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier