Date: Mon, 14 Jul 2014 12:23:33 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Kashyap Desai <kashyap.desai@avagotech.com> Cc: FreeBSD-scsi <freebsd-scsi@freebsd.org> Subject: Re: SSDs peformance on head/freebsd-10 stable using FIO Message-ID: <53C3A195.4020400@FreeBSD.org> In-Reply-To: <a4e86127552716ba989836fbcfc7676b@mail.gmail.com> References: <8fbe38cdad1e66717a9de7fdf63812c2@mail.gmail.com> <53BE8784.8060503@FreeBSD.org> <9f138f242e278476e5c542d695e58bc8@mail.gmail.com> <53BF1E6C.5030806@FreeBSD.org> <a4e86127552716ba989836fbcfc7676b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14.07.2014 11:36, Kashyap Desai wrote: > From: Alexander Motin [mailto:mavbsd@gmail.com] On Behalf Of Alexander >> First thing I noticed in this profile output is bunch of TLB shutdowns. >> You can not reach reasonable performance from user-level without having >> HBA support unmapped I/O. Both mps and mpr drivers support it, but for >> some reason still not mrsas. Even at non-peak I/O rates on multi-core >> system >> TLB shutdowns in such case can eat additional 30% of CPU time. > > Thanks.! For this part, I can try In mrsas. Can you help me to understand > what you mean by unmapped I/O ? That is a capability to work with data not mapped into the kernel virtual address space, i.e. to work with physical addresses instead of virtual. Main prerequisite to support that is that driver should not try to access the transferred data (because it can't do it for addresses not mapped to KVA). If that is true, then usually only minor modification is needed to teach the driver to receive physical addresses from CAM. Looking on mps driver as example you may see PIM_UNMAPPED flag reporting unmapped I/O support to CAM, and bus_dmamap_load_ccb() helper function transparently doing all the physical address handling magic. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53C3A195.4020400>