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@xxxxxx> wrote: >>>> I have an socfpga board, which uses has simple framebuffer implemented >>>> in the FPGA. On 3.15, framebuffer is fast: >>>> >>>> root@wagabuibui:~# 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
Attachment:
signature.asc
Description: OpenPGP digital signature