Re: git: 60381fd1ee86 - main - memdesc: Retire MEMDESC_CCB.
- In reply to: John Baldwin : "Re: git: 60381fd1ee86 - main - memdesc: Retire MEMDESC_CCB."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 17 Jul 2023 18:20:04 UTC
On Mon, Jul 17, 2023 at 12:11 PM John Baldwin <jhb@freebsd.org> wrote: > On 7/17/23 11:07 AM, Warner Losh wrote: > > On Mon, Jul 17, 2023 at 12:02 PM John Baldwin <jhb@freebsd.org> wrote: > > > >> On 7/17/23 10:58 AM, Warner Losh wrote: > >>> On Mon, Jul 17, 2023 at 11:54 AM Konstantin Belousov < > >> kostikbel@gmail.com> > >>> wrote: > >>> Or if it was in cam.h and made a static inline. It's short enough that > >>> won't bloat > >>> the kernel in the half a dozen places its called, and it would give > >> similar > >>> performance > >>> to what we have today with the half a dozen nearly identical copies of > >>> this routine. > >>> And since it's all done with structure dancing, there's no other bits > of > >>> CAM that would > >>> be brought into the kernel. > >> > >> I would be happy with an inline actually, I wasn't sure originally if > that > >> was > >> too invasive in terms of the header bloat it would entail, in particular > >> if it > >> lived in sys/memdesc.h, but maybe it could live in cam_ccb.h? > >> > > > > cam_ccb.h likely is fine, and logically it does belong there more than > cam.h > > now that you mention it... And only sys/kern/subr_bus_dma.c needs it, > > since that's the only place that calls if my grep can be believed. > > I use it in my NVMeoF host, but that is also already including cam_ccb.h > since > it needs to know about CCB internals anyway. > Yea, that sounds like 2 copies in memory of a routine that's kinda small and might be worth the performance improvement with fewer function calls (and even if it not, the hundred or so bytes is a small price to fix this issue, and we do way worse for much flimsier reasons elsewhere in the kernel). Warner