Date: Sun, 13 Dec 2020 16:33:43 -0700 From: Alan Somers <asomers@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, Konstantin Belousov <kostikbel@gmail.com>, Ian Lepore <ian@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: char devices without SI_UNMAPPED? Message-ID: <CAOtMX2jxQ9aWuDnX%2BM9YMHvqb2DsrHPhJGHx_7No4vCQQL_6kw@mail.gmail.com> In-Reply-To: <CAOtMX2j=_UsC=E0WPTHapbPAMycrs_CLiRVEYcMuj2D6Fbudsg@mail.gmail.com> References: <CAOtMX2hFVjFAnNb9wxRTuRsvVptrUsy5C%2BrQECZW-kpKiBXjXA@mail.gmail.com> <6dd927984d69ef0e95e1e90651bcd8087bc4eec4.camel@freebsd.org> <CANCZdfqyLHhuq7h1w7dWh3HoywByOg2RxrezXGTPn_xfYAsTSw@mail.gmail.com> <CAOtMX2iu4ipzdvTer=BzG0hgOiZE2nFHwkrq20bPPoXQe9qkfA@mail.gmail.com> <X9ZuOB7Q3PmOgvvY@kib.kiev.ua> <CAOtMX2jYRkPHpey7JnfvK=2d4i_Qg-LW05M=E9hGVSk2uqXjDQ@mail.gmail.com> <CANCZdfqCKmKjGborNTFv2G-90D9i_Gu692WrDqLysYOdc71OzA@mail.gmail.com> <CAOtMX2j=_UsC=E0WPTHapbPAMycrs_CLiRVEYcMuj2D6Fbudsg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 13, 2020 at 3:06 PM Alan Somers <asomers@freebsd.org> wrote: > On Sun, Dec 13, 2020 at 2:37 PM Warner Losh <imp@bsdimp.com> wrote: > >> >> >> On Sun, Dec 13, 2020 at 1:37 PM Alan Somers <asomers@freebsd.org> wrote: >> >>> On Sun, Dec 13, 2020 at 12:40 PM Konstantin Belousov < >>> kostikbel@gmail.com> wrote: >>> >>>> On Sun, Dec 13, 2020 at 12:20:49PM -0700, Alan Somers wrote: >>>> > On Sun, Dec 13, 2020 at 11:20 AM Warner Losh <imp@bsdimp.com> wrote: >>>> > >>>> > > >>>> > > >>>> > > On Sun, Dec 13, 2020 at 11:18 AM Ian Lepore <ian@freebsd.org> >>>> wrote: >>>> > > >>>> > >> On Sun, 2020-12-13 at 10:27 -0700, alan somers wrote: >>>> > >> > I'm trying to exercise the aio code that handles character >>>> devices >>>> > >> > that >>>> > >> > don't set the SI_UNMAPPED flag. But I can't find any. Are >>>> there any >>>> > >> > remaining character devices that don't allow unmapped I/O? >>>> > >> > >>>> > >> > -Alan >>>> > >> > >>>> > >> >>>> > >> I assume you mean disk-like devices? Probably mmcsd, flash/at45d, >>>> > >> flash/mx25l. >>>> > >> >>>> > > >>>> > Hm. I don't have any of those. >>>> > >>>> > >>>> > > >>>> > > There are times that it's disabled administratively as well, but >>>> that may >>>> > > be on a per-I/O basis. >>>> > > vfs.zfs.vol.unmap_enabled: 1 >>>> > > >>>> > >>>> > This one doesn't seem to work. It looks like the only functionality >>>> it >>>> > gates these days is DIOCGDELETE. >>>> > >>>> > >>>> > > vfs.unmapped_buf_allowed: 1 >>>> > > >>>> > >>>> > Well, this one works. Thanks for the tip. Unfortunately, it's a >>>> tunable, >>>> > so I can't use it for any kind of automated testing. >>>> >>>> There is enough geoms which do not support unmapped bios, even if only >>>> in >>>> some configurations. Recursively grep for G_PF_ACCEPT_UNMAPPED in >>>> sys/geom >>>> to see what I mean. >>>> >>> >>> That's different. If a provider clears G_PF_ACCEPT_UNMAPPED, geom will >>> create a transient mapping for any unmapped bios sent to that provider. >>> But the provider still has SI_UNMAPPED set. SI_UNMAPPED is used in so few >>> places, I'm wondering if it still has a purpose at all. Is it obsolete? >>> >> >> It looks like none of the devices in the tree set it, except the goem >> namespace, the sa CAM device and the geom disk devices. This leaves plenty >> of other devices in the tree that use physio() that aren't marked: pt, >> zvol, altera avgen, altera sd card, amr, cfi, firewire, a bunch of >> different flash devices, mfi, mlx, pst, and twe. >> > > I previously tested zvol and saw that it had SI_UNMAPPED set. But that > was with vfs.zfs.vol.mode=1. With 2, I see that it no longer sets > SI_UNMAPPED. > Oh, and it turns out that there's bug with the ZFS volmode property that also interferes with this test. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251828 . > > >> None of these drivers have been converted over to grok unmapped I/O, >> which is a relatively new feature. Now, some of these devices might have a >> good case made for obsoleting, but they aren't there yet... What makes you >> think this is obsolete? >> > > Just because so few places check it (2), and it was set by all geom > devices. It smelled like the kind of thing that might've been leftover > from before some critical refactor. But I guess I was wrong. > > >> >> Warner >> >> >>> >>>> After all, an option for geom_nop should be trivial, to force all bios >>>> to >>>> map, instead of inheriting from the lower provider. >>>> >>>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jxQ9aWuDnX%2BM9YMHvqb2DsrHPhJGHx_7No4vCQQL_6kw>