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@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
