Date: Sun, 16 Aug 2015 12:03:58 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Roger Pau Monn?? <royger@FreeBSD.org> Cc: Jason Harmening <jason.harmening@gmail.com>, "Jason A. Harmening" <jah@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r286787 - head/sys/x86/x86 Message-ID: <20150816090358.GW2072@kib.kiev.ua> In-Reply-To: <55D046F5.60601@FreeBSD.org> References: <201508142008.t7EK8Hkt037329@repo.freebsd.org> <55CF390F.5010407@FreeBSD.org> <55CF5B13.1040501@gmail.com> <55D046F5.60601@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 16, 2015 at 10:16:53AM +0200, Roger Pau Monn?? wrote: > pmap_map_io_transient contains some of this logic, but it uses > vmem_alloc (with M_WAITOK) instead of a pcpu pageframe, which defeats > part of the purpose of this change and cannot be used as-is. This logic can be repeated, but it is probably too much for the purpose. It would be enough to have single frame (we cannot reuse CMAP1), protected by a spin mutex. I do not see much sense in providing optimized per-cpu frames for this case.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150816090358.GW2072>