Date: Sun, 13 Dec 2020 15:06:39 -0700 From: Alan Somers <asomers@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: 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: <CAOtMX2j=_UsC=E0WPTHapbPAMycrs_CLiRVEYcMuj2D6Fbudsg@mail.gmail.com> In-Reply-To: <CANCZdfqCKmKjGborNTFv2G-90D9i_Gu692WrDqLysYOdc71OzA@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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?CAOtMX2j=_UsC=E0WPTHapbPAMycrs_CLiRVEYcMuj2D6Fbudsg>