Date: Sat, 4 Jul 2020 15:59:16 -0600 From: Alan Somers <asomers@freebsd.org> To: =?UTF-8?Q?Pawe=C5=82_Jakub_Dawidek?= <pawel@dawidek.net> Cc: freebsd-geom@freebsd.org Subject: Re: Single-threaded bottleneck in geli Message-ID: <CAOtMX2idj0pfpo4k%2BxOjaZ9Tk9tLNavNqAo9nGyYOs6OkG7r8w@mail.gmail.com> In-Reply-To: <80B62FE6-FCFB-42B8-A34C-B28E7DDBF45D@dawidek.net> References: <CAOtMX2hHaEzOT0jmc_QcukVZjRKUtCm55bTT9Q5=BNCcL9rf%2Bg@mail.gmail.com> <80B62FE6-FCFB-42B8-A34C-B28E7DDBF45D@dawidek.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I might give this a shot. What is the best way tell if geli ought to use
direct dispatch? Is there a generic "are crypto instructions available"
macro that would cover aesni as well as other platform-specific
instructions?
-Alan
On Sat, Jul 4, 2020, 2:55 PM Pawe=C5=82 Jakub Dawidek <pawel@dawidek.net> w=
rote:
> Direct dispatch would be great for geli, especially that geli can use own
> (multiple) threads when necessary (eg. using crypto cards). With AES-NI y=
ou
> could go straight to the disk.
>
> --
> Pawe=C5=82 Jakub Dawidek
>
>
>
> > On Jul 3, 2020, at 13:22, Alan Somers <asomers@freebsd.org> wrote:
> >
> > =EF=BB=BFI don't. What I meant was that a single thread (geom) is limi=
ting the
> > performance of the system overall. I'm certain, based on top, gstat, a=
nd
> > zpool iostat, that geom is the limiting factor on this system.
> > -Alan
> >
> >> On Fri, Jul 3, 2020 at 2:18 PM Pawe=C5=82 Jakub Dawidek <pawel@dawidek=
.net>
> >> wrote:
> >>
> >> Hi Alan,
> >>
> >> why do you think it will hurt single-threaded performance?
> >>
> >> --
> >> Pawe=C5=82 Jakub Dawidek
> >>
> >>
> >>
> >>>> On Jul 3, 2020, at 12:30, Alan Somers <asomers@freebsd.org> wrote:
> >>>
> >>> =EF=BB=BFI'm using geli, gmultipath, and ZFS on a large system, with =
hundreds
> of
> >>> drives. What I'm seeing is that under at least some workloads, the
> >> overall
> >>> performance is limited by the single geom kernel process. procstat a=
nd
> >>> kgdb aren't much help in telling exactly why this process is using so
> >> much
> >>> CPU, but it certainly must be related to the fact that over 15,000 IO=
Ps
> >> are
> >>> going through that thread. What can I do to improve this situation?
> >> Would
> >>> it make sense to enable direct dispatch for geli? That would hurt
> >>> single-threaded performance, but probably improve performance for
> highly
> >>> multithreaded workloads like mine.
> >>>
> >>> Example top output:
> >>> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU
> COMMAND
> >>> 13 root -8 - 0B 96K CPU46 46 82.7H 70.54%
> >>> geom{g_down}
> >>> 13 root -8 - 0B 96K - 9 35.5H 25.32%
> >>> geom{g_up}
> >>>
> >>> -Alan
> >>> _______________________________________________
> >>> freebsd-geom@freebsd.org mailing list
> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-geom
> >>> To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.or=
g
> "
> >>
> >>
> > _______________________________________________
> > freebsd-geom@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-geom
> > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org"
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2idj0pfpo4k%2BxOjaZ9Tk9tLNavNqAo9nGyYOs6OkG7r8w>