ddsnap performance is slow with 2.6.24.2 kernel
GoogleCodeExporter opened this issue · comments
The performance of ddsnap with our latest 2.6.24.2 kernel is about 30%
slower than that with the 2.6.22.18 kernel. Enabling/Disabling
bio_throttling does not seem to have big impact on the performance. The
problem exists on both lvm devices and raw devices. It seems to be caused
by some mainline kernel change.
Original issue reported on code.google.com by jiahotc...@gmail.com on 5 Jun 2008 at 11:11
Here are some updates. I found 2.6.24 kernel includes a
per-device-dirty-threshold
patch by Peter Zijlstra that might be related to this slow performance issue.
In the
attachment is a patch that reverts the major part of Peter's patch. It seems to
have
solved the performance issue on my testing machine. Can anyone else also give
it a
try? Thanks!
Jiaying
Original comment by jiayin...@gmail.com on 7 Jun 2008 at 12:15
Attachments:
FYI, here is an article about Peter's per-dev-dirty-thresholds patch
http://lwn.net/Articles/245600/
The patch is intended to solve the unbalanced write throttling among
multiple/stacked
devices and prevent the potential deadlock in stacked devices.
While looking at the problem, I found kernelnewbies.org has good description on
each
major kernel release. Here is the link for 2.6.24.
http://kernelnewbies.org/Linux_2_6_24#head-92340ffcec39e7c2a09fd933243fb18eda57f
1b4
Jiaying
Original comment by jiayin...@gmail.com on 7 Jun 2008 at 12:38
Attaching dmsetup trace from 2.6.25.4 using this patch.
Original comment by williama...@gmail.com on 11 Jun 2008 at 12:21
Attachments:
Will,
Did you try the 2.6.25.4 patch I posted before? The problem looks similar to
the one
I saw when I first tried ddsnap patches with 2.6.25.4 kernel. I disabled the
BLK in
ddsnap_create and then ddsnap works on my testing machine. But I still got
kernel
panic during 'dmsetup create' on uml.
Original comment by jiahotc...@gmail.com on 15 Jun 2008 at 7:46
The 2.6.25.4 patches worked with UML, but gave that panic on real hardware.
Original comment by compbr...@gmail.com on 16 Jun 2008 at 4:21