<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Massive slowdown under specific memcpy implementations (32bit, no-SIMD, backward copy)." href="https://bugs.freedesktop.org/show_bug.cgi?id=107670#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Massive slowdown under specific memcpy implementations (32bit, no-SIMD, backward copy)." href="https://bugs.freedesktop.org/show_bug.cgi?id=107670">bug 107670</a> from <a class="email" href="mailto:iive@yahoo.com" title="iive@yahoo.com">iive@yahoo.com</a> <pre>(In reply to Roland Scheidegger from <a href="show_bug.cgi?id=107670#c3">comment #3</a>) > Isn't this mapped as WC? > In this case I'd expect the direction to make little difference, since write > combine of any decent cpu should be able to combine the writes regardless > the order? > Although if it's UC I suppose someone needs to ensure that the maximum > possible size is picked... The theory that this is a caching issue has a merit since the distribution version and my build seem to use the exact same memcpy(), one that goes backwards, yet the distribution one is not triggering the massive slowdown. The memmove() uses `rep movsb` and direction flag. The question is, what controls the cache? How userland Mesa3D controls the PAT cache flags? Because I am just changing the libraries, without rebooting machine or restarting Xorg, I don't even stop the steam client. This means that MTRR registers are not changed and the exact same kernel module and configuration is used. I do use modified build script, that disables support for hardware I don't have, like intel and nvidia. Some of my options might cause the cache problem, but I need to know what I am looking for. BTW, the system libdrm is latest version (2.4.92).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>