Knut Petersen wrote:

Hi everybody!

quoted

quoted

I haven't seen any significant performance penalty, between 
2.6.12-rc5-mm1
and 2.6.13-rc3-mm1.

Based on your results, I would pinpoint the culprit to be in
video/console/bitblit.c.  However, the changes there are minor, and 
should not
alter the peformance.

So.. what happened here?  Is the problem still present in 2.6.13-rc4?

Yes, the problem still is present in 2.6.13-rc4.
================================================

Thank you for your persistence.  I think I know the culprit.  Someone
insisted on using memcpy in fb_pad_aligned_buffer().  I have already
fixed this before, but apparently, the memcpy was brought back.  Try
the attached patch and let me know.

Tony

   fbdev: Replace memcpy with for-loop when preparing bitmap

    Do not use memcpy in fb_pad_aligned_buffer. It is suboptimal because only
    a few bytes are moved at a time. Replace with a for-loop.

    From: Antonino Daplas [off-list ref]
    Signed-off-by: Antonino Daplas [off-list ref]
---

 fbmem.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c

@@ -80,10 +80,12 @@ EXPORT_SYMBOL(fb_get_color_depth);
  */
 void fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 s_pitch, u32 height)
 {
-	int i;
+	int i, j;
 
 	for (i = height; i--; ) {
-		memcpy(dst, src, s_pitch);
+		/* s_pitch is a few bytes at the most, memcpy is suboptimal */
+		for (j = 0; j < s_pitch; j++)
+			dst[j] = src[j];
 		src += s_pitch;
 		dst += d_pitch;
 	}


-------------------------------------------------------

SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf