Date: Mon, 17 Aug 2015 11:58:55 +0200 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= <royger@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> 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: <55D1B05F.8040101@FreeBSD.org> In-Reply-To: <20150816095004.GX2072@kib.kiev.ua> References: <201508142008.t7EK8Hkt037329@repo.freebsd.org> <55CF390F.5010407@FreeBSD.org> <55CF5B13.1040501@gmail.com> <55D046F5.60601@FreeBSD.org> <20150816090358.GW2072@kib.kiev.ua> <20150816095004.GX2072@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
El 16/08/15 a les 11.50, Konstantin Belousov ha escrit: > On Sun, Aug 16, 2015 at 12:03:58PM +0300, Konstantin Belousov wrote: >> 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. > > Like this. I only compiled the patch. Thanks, yes, this looks right. Since this is only used for the bounce buffer code I don't think it's necessary to have a per-cpu frame. If the usage of this function is expanded I might look into adding a per-cpu frame. Roger.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55D1B05F.8040101>