From owner-freebsd-hackers@freebsd.org Sun Dec 13 22:06:52 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 172654C52B2 for ; Sun, 13 Dec 2020 22:06:52 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (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 4CvJXC7109z3FB2; Sun, 13 Dec 2020 22:06:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f51.google.com with SMTP id h18so13923579otq.12; Sun, 13 Dec 2020 14:06:51 -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:to:cc; bh=ziGMNRr73f0i18k58zE2IQMm52yiMOl3TGbj5G7yA8A=; b=EQfND+Y2qGdwcsVMTEKdo7/XMfShz5xoFIdbMYzB1IHuyTrnlaJbqP7kwtYWYEYwD8 h3aftGF/sSY/BQ7ub5Rr/PgXyCP1ELU1uf3mqSdHEfoke60QjxDbhwFVzx3l3xvbTk2j pklFoiFFhm1X0RnFIOg+EDjAxV7VLpcXh6MpdrZjUOGsWBKnyK1vMXvO+wm/HoCSx/qE p3Y+CR57uPOIZFPOBri1AZUGRz11LX+LufwyRr3h0mEZwsv/iRO9EgLJNOgSbVGBDH5A qisQ/RtYOnMIFAxJABzfv8NzcwCfGPaxfvBzfM4a3R0SsRGuWl2R0RT2lwviZV6BZH2h QeEA== X-Gm-Message-State: AOAM530vBTHzgr308bh9G3PLieJmctqT0ZNmjdBOhYkqo189Oqckg1y3 K+oJ0l2Fzx6Jtv62QlosHMhGr+m1wQQUF/oCApk= X-Google-Smtp-Source: ABdhPJzyOXpGQKqPlUvLfsqPI9+ep8Ku/iUdEBCRfjqXhuiLIi9075HBHNCx2VlYzB6jpKd0kZP9b/YovxnIhqDlL4o= X-Received: by 2002:a05:6830:30a8:: with SMTP id g8mr11790066ots.291.1607897210678; Sun, 13 Dec 2020 14:06:50 -0800 (PST) MIME-Version: 1.0 References: <6dd927984d69ef0e95e1e90651bcd8087bc4eec4.camel@freebsd.org> In-Reply-To: From: Alan Somers Date: Sun, 13 Dec 2020 15:06:39 -0700 Message-ID: Subject: Re: char devices without SI_UNMAPPED? To: Warner Losh Cc: Konstantin Belousov , Ian Lepore , FreeBSD Hackers X-Rspamd-Queue-Id: 4CvJXC7109z3FB2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] 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 22:06:52 -0000 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 >> 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. > 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. >>> >>