On 09/12/2013 01:03 AM, Mikulas Patocka wrote: > > Tests were done on two six-core Istanbul-class Opterons. > > I don't have a computer with AES-NI, so I can't test that. AES-NI is used almost in all systems where is dmcrypt currently deployed (notebooks typically)... so I think it must be tested there. Also ramdisk tests are good baseline but this is not real world scenario. I would really like to see the same test with RAID5 (over fast rotational disks) with various stripe size and for SSDs (and RAID0 with SSDs). (These were reported problematic scenarios in recent years I know about.) Can you also show how the sorting patch influences performance? (IOW how it performs without it.) Another problematic part was latency (e.g. sql database over dmcrypt doesn't perform well). Isn't it even worse with these patches? (I am not sure if anyone have fio script to simulate such workload.) I would like to test it myself but I have no usable fast-enough test systems at all currently. But there are surely some in RH. (Added cc to Ondra, he has some test scripts I used.) I also remember I tried your patches (year ago) with limited CPU workqueues (I mean using e.g. only 3 of 6 cores) and it performed better in some tests. This support Andi's suggestion to limit it to smaller groups of cpus. Also I think we discussed this should be configurable through optional dmcrypt per-device parameters (e.g. I would like to set up some dmcrypt device to use only one CPU). Think about backend for virtual machines etc, it should not eat all available CPUs power on host... Do you plan to add such patch as well? Milan -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
