[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdXWRx7bKWhQuWH05CbPTXPy5imCUcW1xUf2E8f7BtF9NQ@mail.gmail.com>
Date: Tue, 7 Apr 2015 14:19:33 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Pavel Machek <pavel@....cz>
Cc: Marek Vasut <marek.vasut@...il.com>,
kernel list <linux-kernel@...r.kernel.org>,
Dinh Nguyen <dinh.linux@...il.com>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
Tomi Valkeinen <tomi.valkeinen@...com>,
Grant Likely <grant.likely@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Jingoo Han <jg1.han@...sung.com>,
Rob Clark <robdclark@...il.com>,
Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: simple framebuffer slower by factor of 20, on socfpga (arm) platform
Hi Pavel,
On Tue, Apr 7, 2015 at 2:12 PM, Pavel Machek <pavel@....cz> wrote:
> I have an socfpga board, which uses has simple framebuffer implemented
> in the FPGA. On 3.15, framebuffer is fast:
>
> root@...abuibui:~# time cat /dev/fb0 > /dev/null
> real 0m 0.00s
> user 0m 0.00s
> sys 0m 0.00s
>
> on 3.18, this takes 220msec. Similar slowdown exists for
> writes. Simple framebuffer did not change at all between 3.15 and
> 3.18; resource flags of the framebuffer are still same (0x200).
>
> If I enable caching on 3.18, it speeds up a bit, to 70msec or
> so... Which means problem is not only in caching.
>
> Any ideas?
My first guess was commit 67dc0d4758e5 ("vt_buffer: drop console buffer
copying optimisations"), but this was introduced only in v4.0-rc1.
Just in case you encounter another performance regression after upgrading
to a more modern kernel ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists