• Dave Airlie's avatar
    efifb: allow user to disable write combined mapping. · dd0c41f8
    Dave Airlie authored
    This patch allows the user to disable write combined mapping
    of the efifb framebuffer console using an nowc option.
    
    A customer noticed major slowdowns while logging to the console
    with write combining enabled, on other tasks running on the same
    CPU. (10x or greater slow down on all other cores on the same CPU
    as is doing the logging).
    
    I reproduced this on a machine with dual CPUs.
    Intel(R) Xeon(R) CPU E5-2609 v3 @ 1.90GHz (6 core)
    
    I wrote a test that just mmaps the pci bar and writes to it in
    a loop, while this was running in the background one a single
    core with (taskset -c 1), building a kernel up to init/version.o
    (taskset -c 8) went from 13s to 133s or so. I've yet to explain
    why this occurs or what is going wrong I haven't managed to find
    a perf command that in any way gives insight into this.
    
        11,885,070,715      instructions              #    1.39  insns per cycle
    vs
        12,082,592,342      instructions              #    0.13  insns per cycle
    
    is the only thing I've spotted of interest, I've tried at least:
    dTLB-stores,dTLB-store-misses,L1-dcache-stores,LLC-store,LLC-store-misses,LLC-load-misses,LLC-loads,\mem-loads,mem-stores,iTLB-loads,iTLB-load-misses,cache-references,cache-misses
    
    For now it seems at least a good idea to allow a user to disable write
    combining if they see this until we can figure it out.
    
    Note also most users get a real framebuffer driver loaded when kms
    kicks in, it just happens on these machines the kernel didn't support
    the gpu specific driver.
    Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
    Acked-by: default avatarPeter Jones <pjones@redhat.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    dd0c41f8
efifb.c 11.5 KB