Date: Mon, 17 Jul 2023 12:20:04 -0600 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 60381fd1ee86 - main - memdesc: Retire MEMDESC_CCB. Message-ID: <CANCZdfpVYbsWVKCb1cpyrXwUF=XGV39%2BU%2BUe_tXhKvsW=e=q0A@mail.gmail.com> In-Reply-To: <09687219-240b-c1a5-8e5a-956b231854d5@FreeBSD.org> References: <202307141841.36EIf3f0019403@gitrepo.freebsd.org> <ZLVizUl1Xyo1AQmy@kib.kiev.ua> <65d7d8d8-9f98-abd2-1ce3-ae3a2d3bf111@FreeBSD.org> <CANCZdfoHid=H1Ys_4XTJPfCaifevSoW92nGYXU3Ot=mTT13T%2Bg@mail.gmail.com> <ZLWARmA8XYh3wR6C@kib.kiev.ua> <CANCZdfpcbqgEV6Exuj-eGcr9yWuDHcdDvXfK4FZQVZCO8BwcjQ@mail.gmail.com> <92656b28-8bfa-23a9-2683-23ccb817b8a7@FreeBSD.org> <CANCZdfoFR7%2BZpcMTc1rnYDGc-KM98=a0-U0Zp_4eEqmzwSPemA@mail.gmail.com> <09687219-240b-c1a5-8e5a-956b231854d5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000a445b00600b2d9d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 17, 2023 at 12:11=E2=80=AFPM John Baldwin <jhb@freebsd.org> wro= te: > On 7/17/23 11:07 AM, Warner Losh wrote: > > On Mon, Jul 17, 2023 at 12:02=E2=80=AFPM John Baldwin <jhb@freebsd.org>= wrote: > > > >> On 7/17/23 10:58 AM, Warner Losh wrote: > >>> On Mon, Jul 17, 2023 at 11:54=E2=80=AFAM Konstantin Belousov < > >> kostikbel@gmail.com> > >>> wrote: > >>> Or if it was in cam.h and made a static inline. It's short enough tha= t > >>> 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 o= f > >>> 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 particul= ar > >> 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 --000000000000a445b00600b2d9d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 17, 2023 at 12:11=E2=80= =AFPM John Baldwin <<a href=3D"mailto:jhb@freebsd.org">jhb@freebsd.org</= a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p= x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On= 7/17/23 11:07 AM, Warner Losh wrote:<br> > On Mon, Jul 17, 2023 at 12:02=E2=80=AFPM John Baldwin <<a href=3D"m= ailto:jhb@freebsd.org" target=3D"_blank">jhb@freebsd.org</a>> wrote:<br> > <br> >> On 7/17/23 10:58 AM, Warner Losh wrote:<br> >>> On Mon, Jul 17, 2023 at 11:54=E2=80=AFAM Konstantin Belousov &= lt;<br> >> <a href=3D"mailto:kostikbel@gmail.com" target=3D"_blank">kostikbel= @gmail.com</a>><br> >>> wrote:<br> >>> Or if it was in cam.h and made a static inline. It's short= enough that<br> >>> won't bloat<br> >>> the kernel in the half a dozen places its called, and it would= give<br> >> similar<br> >>> performance<br> >>> to what we have today with the half a dozen nearly identical c= opies of<br> >>> this routine.<br> >>> And since it's all done with structure dancing, there'= s no other bits of<br> >>> CAM that would<br> >>> be brought into the kernel.<br> >><br> >> I would be happy with an inline actually, I wasn't sure origin= ally if that<br> >> was<br> >> too invasive in terms of the header bloat it would entail, in part= icular<br> >> if it<br> >> lived in sys/memdesc.h, but maybe it could live in cam_ccb.h?<br> >><br> > <br> > cam_ccb.h likely is fine, and logically it does belong there more than= cam.h<br> > now that you mention it...=C2=A0 And only sys/kern/subr_bus_dma.c need= s it,<br> > since that's the only place that calls if my grep can be believed.= <br> <br> I use it in my NVMeoF host, but that is also already including cam_ccb.h si= nce<br> it needs to know about CCB internals anyway.<br></blockquote><div><br></div= ><div>Yea, that sounds like 2 copies in memory of a routine that's kind= a small and might</div><div>be worth the performance improvement with fewer= function calls (and even if it not,</div><div>the hundred or so bytes is a= small price to fix this issue, and we do way worse for</div><div>much flim= sier reasons elsewhere in the kernel).</div><div><br></div><div>Warner=C2= =A0</div></div></div> --000000000000a445b00600b2d9d1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpVYbsWVKCb1cpyrXwUF=XGV39%2BU%2BUe_tXhKvsW=e=q0A>