Date: Mon, 29 Aug 2016 21:11:32 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Bruce Evans <brde@optusnet.com.au> Cc: Bruce Evans <bde@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r305004 - in head/sys: amd64/amd64 amd64/include i386/i386 Message-ID: <20160829181132.GR88122@zxy.spb.ru> In-Reply-To: <20160830034632.A3851@besplex.bde.org> References: <201608291307.u7TD7L6H025649@repo.freebsd.org> <20160829173726.GX22212@zxy.spb.ru> <20160830034632.A3851@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 30, 2016 at 03:58:54AM +1000, Bruce Evans wrote: > On Mon, 29 Aug 2016, Slawa Olhovchenkov wrote: > > > On Mon, Aug 29, 2016 at 01:07:21PM +0000, Bruce Evans wrote: > >> ... > >> Log: > >> On amd64, declare sse2_pagezero() and start using it again, but only > >> for zeroing pages in idle where nontemporal writes are clearly best. > >> This is almost a no-op since zeroing in idle works does nothing good > >> and is off by default. Fix END() statement forgotten in previous > >> commit. > >> ... > > > > Do you think about using nontemporal writes for copying from user > > space to kernel space? In much cases this copy result don't need any parsing > > anf just go to DMA, eliminate cache use. > > I once tried that (for copyin/out, without DMA). It was just a small > pessimization. For small data, it increases setup overheads, and > large data isn't common enough to matter. DMA can be even slower > since it increases latency. First there is latency to set it up, > and May be I am not very clear: not using DMA for tranfer. Using nontemporal for data passed to devices DMA buffers. > then you often don't want it to touch the cache since that gives more > latency for cache misses. No, I am talk not about total replace such copy, only on per-case bases. I.e. introduce new function and use it in special cases (for example: tcp output).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160829181132.GR88122>