Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 13 Dec 2020 14:36:51 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Alan Somers <asomers@freebsd.org>
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:  <CANCZdfqCKmKjGborNTFv2G-90D9i_Gu692WrDqLysYOdc71OzA@mail.gmail.com>
In-Reply-To: <CAOtMX2jYRkPHpey7JnfvK=2d4i_Qg-LW05M=E9hGVSk2uqXjDQ@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>

next in thread | previous in thread | raw e-mail | index | archive | help
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. 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?

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?CANCZdfqCKmKjGborNTFv2G-90D9i_Gu692WrDqLysYOdc71OzA>