From owner-svn-src-all@freebsd.org Tue Apr 16 15:31:24 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B33711575B63; Tue, 16 Apr 2019 15:31:24 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 530956A645; Tue, 16 Apr 2019 15:31:24 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 216A821824; Tue, 16 Apr 2019 15:31:24 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id x3GFVNma070469; Tue, 16 Apr 2019 15:31:23 GMT (envelope-from bde@FreeBSD.org) Received: (from bde@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id x3GFVNY3070468; Tue, 16 Apr 2019 15:31:23 GMT (envelope-from bde@FreeBSD.org) Message-Id: <201904161531.x3GFVNY3070468@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bde set sender to bde@FreeBSD.org using -f From: Bruce Evans Date: Tue, 16 Apr 2019 15:31:23 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r346278 - head/lib/libvgl X-SVN-Group: head X-SVN-Commit-Author: bde X-SVN-Commit-Paths: head/lib/libvgl X-SVN-Commit-Revision: 346278 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 530956A645 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 15:31:25 -0000 Author: bde Date: Tue Apr 16 15:31:23 2019 New Revision: 346278 URL: https://svnweb.freebsd.org/changeset/base/346278 Log: Quick fix for slow clearing and context switches of large frame buffers with old kernels, by breaking the support for large frame buffers in the same way as for current kernels. Large frame buffers may be too large to map into kva, and the kernel (syscons) only uses the first screen page anyway, so r203535, r205557 and 248799 limit the buffer size in VESA modes to the first screen page, apparently without noticing that this breaks applications by using the same limit for user mappings as for kernel mappings. In vgl, this makes the virtual screen the same as the physical screen. However, this is almost a feature since clearing and switching large (usually mostly unused) frame buffers takes too long. E.g., on a 16 year old low-end AGP card it takes about 12 seconds to clear the 128MB frame buffer in old kernels that map it all and also map it with slow attributes (e.g., uncacheable). Older PCI cards are even slower, but usually have less memory. Newer PCIe cards are faster, but may have many GB of memory. Also, vgl malloc()s a shadow buffer with the same size as the frame buffer, so large frame buffers are even more wasteful in applications than in the kernel. Use the same limit in vgl as in newer kernels. Virtual screens and panning still work in non-VESA modes that have more than 1 page. The reduced buffer size in the kernel also breaks mmap() of the last physical page in modes where the reduced size is not a multiple of the physical page size. The same reduction in vgl only reduces the virtual screen size. Modified: head/lib/libvgl/main.c Modified: head/lib/libvgl/main.c ============================================================================== --- head/lib/libvgl/main.c Tue Apr 16 14:29:12 2019 (r346277) +++ head/lib/libvgl/main.c Tue Apr 16 15:31:23 2019 (r346278) @@ -264,6 +264,19 @@ VGLInit(int mode) else VGLBufSize = max(VGLAdpInfo.va_line_width*VGLModeInfo.vi_height, VGLAdpInfo.va_window_size)*VGLModeInfo.vi_planes; + /* + * The above is for old -CURRENT. Current -CURRENT since r203535 and/or + * r248799 restricts va_buffer_size to the displayed size in VESA modes to + * avoid wasting kva for mapping unused parts of the frame buffer. But all + * parts were usable here. Applying the same restriction to user mappings + * makes our virtualization useless and breaks our panning, but large frame + * buffers are also difficult for us to manage (clearing and switching may + * be too slow, and malloc() may fail). Restrict ourselves similarly to + * get the same efficiency and bugs for all kernels. + */ + if (0 && VGLModeInfo.vi_mode >= M_VESA_BASE) + VGLBufSize = 2*VGLAdpInfo.va_line_width*VGLModeInfo.vi_height* + VGLModeInfo.vi_planes; VGLBuf = malloc(VGLBufSize); if (VGLBuf == NULL) { VGLEnd();