On Tue, Aug 14, 2018 at 9:54 PM Johannes Lundberg <johalun0_at_gmail.com> wrote: > > > On Tue, Aug 14, 2018 at 3:39 PM Konstantin Belousov <kostikbel_at_gmail.com> > wrote: > >> On Tue, Aug 14, 2018 at 08:55:36AM -0500, Eric van Gyzen wrote: >> > On 8/14/18 4:12 AM, Johannes Lundberg wrote: >> > > Hi >> > > >> > > Something that we have seen for a long time on FreeBSD is the boot >> message >> > > >> > > Failed to add WC MTRR for [0xd0000000-0xdfffffff]: -22; performance >> may >> > > suffer >> > > >> > > Taking a closer look at this with memcontrol I can see that the 256 MB >> > > region that DRM wants to set as WC is already covered by this entry >> > > 0xc0000000/0x40000000 BIOS uncacheable set-by-firmware active >> > > >> > > Similar on both my Skylake and Broadwell systems. >> > I see something similar on my Dell XPS 13 with a Kaby Lake R: >> > >> > Failed to add WC MTRR for [0x90000000-0x9fffffff]: -22; performance may >> > suffer >> > >> > 0x80000000/0x80000000 BIOS uncacheable set-by-firmware active >> > >> > The only mappings in this range are MMIO: >> > >> > machdep.efi_map: >> > Type Physical Virtual #Pages Attr >> > [snip] >> > MemoryMappedIO 0000e0000000 0xe0000000 00010000 RUNTIME >> > MemoryMappedIO 0000fe000000 0xfe000000 00000011 UC RUNTIME >> > MemoryMappedIO 0000fec00000 0xfec00000 00000001 UC RUNTIME >> > MemoryMappedIO 0000fee00000 0xfee00000 00000001 UC WT WB WP RUNTIME >> > MemoryMappedIO 0000ff000000 0xff000000 00001000 UC WT WB WP RUNTIME >> >> Yes, the cause of the message is that current x86 mtrr code is not >> sufficient to handle this situation. You have BIOS-configured variable >> range MTRR which covers upper half of the low 4G, as uncacheable (UC). >> It is reasonable for BIOS to set it up this way because this is where >> PCIe BARs and other devices MMIO regions are located. >> >> One of the BARs there is the GPU aperture that really should be WC >> (write-combining). There are two ways to achieve this: split the UC >> variable-length MTRR range into three, UC/WC/UC, which would require >> three MTRRs to cover. This is what current x86_mem.c code does not >> support. >> >> Another way is to set WC mode in the page table entries (PTEs) using >> Page Attribute Table (PAT), for all PTEs. According to the rules of >> combination of the memory access types between MTRR and PAT, WC in PAT >> and any access mode in MTRR gives effective WC. >> >> I saw the same warning when I initially ported GEM. My code used WC PAT >> type, which makes the warning cosmetical, and which made me to not add >> MTRR split. If new drm driver also consistently uses WC memattr when >> creating aperture mappings, then the warning can be ignored as well. >> > > Hi Kib > > Thanks for the detailed answer. This might already be the case for the out > of tree drivers as well. From what I read about the VESA driver the > performance difference should be quite big w/o WC and I haven't noticed and > performance issues with the newer drivers at all. > > I will confirm this tomorrow. > Yeah, seems like it's already done. https://github.com/FreeBSDDesktop/kms-drm/blob/drm-v4.15/linuxkpi/gplv2/src/linux_page.c#L260 https://github.com/FreeBSDDesktop/kms-drm/blob/drm-v4.15/drivers/gpu/drm/i915/i915_gem_gtt.c#L415 https://github.com/FreeBSDDesktop/kms-drm/blob/drm-v4.15/drivers/gpu/drm/ttm/ttm_page_alloc.c#L534 > > _______________________________________________ >> freebsd-current_at_freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org >> " >> >Received on Thu Aug 16 2018 - 08:11:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:17 UTC