linux-kernel - Re: simple framebuffer slower by factor of 20, on socfpga (arm) platform

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <552663C2.70308@ti.com>
Date:	Thu, 9 Apr 2015 14:34:26 +0300
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	Pavel Machek <pavel@....cz>
CC:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	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>,
	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>,
	<shc_work@...l.ru>, <linux@....linux.org.uk>,
	<hsweeten@...ionengravers.com>,
	Archit Taneja <architt@...eaurora.org>
Subject: Re: simple framebuffer slower by factor of 20, on socfpga (arm) platform

On 09/04/15 14:21, Tomi Valkeinen wrote:
> On 09/04/15 14:06, Pavel Machek wrote:
>> On Tue 2015-04-07 14:19:33, Geert Uytterhoeven wrote:
>>> 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 ;-)
>>
>> :-). I did a git bisect, and it pointed to this. And reverting it
>> indeed fixes the problem in 3.18. Problem is still there in 4.0.

The difference is probably caused by memcpy() vs memcpy_fromio(). The
comment above memcpy_fromio() says "This needs to be optimized". I think
generally speaking memcpy_fromio() is correct for a framebuffer.

That said, if the fb is in RAM, and is only written by the CPU, I think
a normal memcpy() for fb_memcpy_fromfb() should be fine...

 Tomi



Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)