From owner-freebsd-hackers@freebsd.org Sun Dec 13 23:33:56 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 42C014C7B82 for ; Sun, 13 Dec 2020 23:33:56 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CvLSg3Kw8z3PHY for ; Sun, 13 Dec 2020 23:33:55 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f44.google.com with SMTP id b18so14077503ots.0 for ; Sun, 13 Dec 2020 15:33:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=RoEUineAu9lMg3aTPtDqW6we0E9iwm1BqbQU41B/ePI=; b=Q5CzkZoJHnwfg9/5FcWOL7MiSP+p4/CADwudb5qxFaatiwlLA77t6dASEw5YZRA3P7 L447xaXL7lzpyl6YXveP+mGEXUtB36t57+9UbIKi27xzDBlisrpbGgJ0TeyfpBh5mRGg q/n/rK4ySies51k4Pbq9wr3Pma8xND+5t0Shtzb0Vfo8M/NroTRsAGLGZxl62aH//jq6 QEtFFu6xCPJKOcv4n3Xzf/gNL3mjbdu0r7IYmgOzOLxXjuSopqazfcpRkkO9dues9EUo 1fHHxQoDBjkaAzzxFEAyen9eZi+tcvTBor0yapCH+XS7d5POT3Op4eQbf3ZJQSTnfHAK 3Qmg== X-Gm-Message-State: AOAM532bh9EmKKUWXx5A/acex8gFc4Qw8PflpgJp1vD7/aV0ZUETQ8+0 2CLV5bnobwuKBLu/NGckR077c/YJDgHWoBGN6qU= X-Received: by 2002:a05:6830:30a8:: with SMTP id g8mt12245295ots.291.1607902434261; Sun, 13 Dec 2020 15:33:54 -0800 (PST) MIME-Version: 1.0 References: <6dd927984d69ef0e95e1e90651bcd8087bc4eec4.camel@freebsd.org> In-Reply-To: From: Alan Somers Date: Sun, 13 Dec 2020 16:33:43 -0700 Message-ID: Subject: Re: char devices without SI_UNMAPPED? Cc: Warner Losh , Konstantin Belousov , Ian Lepore , FreeBSD Hackers X-Rspamd-Queue-Id: 4CvLSg3Kw8z3PHY X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.44 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [0.08 / 15.00]; RCVD_TLS_ALL(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.44:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.92)[-0.923]; MISSING_TO(2.00)[]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.210.44:from]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; SPAMHAUS_ZRD(0.00)[209.85.210.44:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.44:from]; FREEMAIL_CC(0.00)[bsdimp.com,gmail.com,freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2020 23:33:56 -0000 On Sun, Dec 13, 2020 at 3:06 PM Alan Somers wrote: > On Sun, Dec 13, 2020 at 2:37 PM Warner Losh wrote: > >> >> >> On Sun, Dec 13, 2020 at 1:37 PM Alan Somers 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 wrote: >>>> > >>>> > > >>>> > > >>>> > > On Sun, Dec 13, 2020 at 11:18 AM Ian Lepore >>>> 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. >>>> >>>