From owner-freebsd-hackers@freebsd.org Sun Dec 13 21:37:03 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 27EC24C4932 for ; Sun, 13 Dec 2020 21:37:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 4CvHsq0R68z3Cfn for ; Sun, 13 Dec 2020 21:37:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x732.google.com with SMTP id h4so9073039qkk.4 for ; Sun, 13 Dec 2020 13:37:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g2/mtZC3yfLAmX9XczVdT/a0PzKGA3HnxXiX1OGxRZ4=; b=dAXDclNiLOBhy0vODjh7XCQZeAVRIWw06+QeIO/nEkhY6aLq2G2IejnxbjOWWhazN3 Tj6jI1aJt191uj3+XPuD2vfPca0SRmgRm00N+uF/YytlaF0R3ebGpEdrzYsJH33h5fcP q37ERPnrRB+xN8o7CXhBBSuYGcCeleC4qajyHzYaSPvdRymo1GrWZ166wkEqtF+2KGL0 uM3bDFXhwxDc74pAwnqaMs2qjP/Va1oXZm72Gr2OooVCgzL6yYlqhoTa8R7cTXkELcBV diSpPn4Mpawvl7tyTmTRNfIsTB7NZeufkma/Od0G0m8d/O06syvaOyVjs0WixSxW0bAV PBcg== 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=g2/mtZC3yfLAmX9XczVdT/a0PzKGA3HnxXiX1OGxRZ4=; b=earTeIs3mKnFVEeEq7zF+2Uj3+8oHqf3/+8pwISt2CxHkzugshQALsboQY+ZMNpz1Y 5DrD/tRfqoRZJYcfEULx2Omd8WM0TJLjV9sg8SITk+XRc7BloA8UgfAeosVURlEsZ5Gw BLJ2aE8yUfGiFwFkixuitAe1kbABjnXjdn+JTgzY9hpu5iup0f05VqJIAPfIXMA/3jao ZT0qIO1GzkGxAUvVT4NuzFxDCrE9r4lnstB16GcEXaMgkljmrGekdF9+Lr+tTKfMqgsQ NK62pOpdIBgAt0anonyGCHwTpsTo5Taol3IW+GURZ+K8hNgW5gXchoSkl5aUWtnUiw2K GUGA== X-Gm-Message-State: AOAM532A/SYcbot48NrtkGivtOxOosMLlTl0wo4sVKOEDd5/D76ciU31 5r2Z/YVQYPnAnhk5K7zmoQnpvr6+Q9ME2B1gZMRnzw== X-Google-Smtp-Source: ABdhPJyl+P9S1hPl8jD+KC3Jb+SwWB9mb7PewTiKNaqM0HSvWMmKvSGcW0q5zYBLhBJ3xYeQd7cI+MhIbs7vGEyoJSA= X-Received: by 2002:a37:4a4e:: with SMTP id x75mr18890129qka.89.1607895421947; Sun, 13 Dec 2020 13:37:01 -0800 (PST) MIME-Version: 1.0 References: <6dd927984d69ef0e95e1e90651bcd8087bc4eec4.camel@freebsd.org> In-Reply-To: From: Warner Losh Date: Sun, 13 Dec 2020 14:36:51 -0700 Message-ID: Subject: Re: char devices without SI_UNMAPPED? To: Alan Somers Cc: Konstantin Belousov , Ian Lepore , FreeBSD Hackers X-Rspamd-Queue-Id: 4CvHsq0R68z3Cfn 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 21:37:03 -0000 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. 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. >> >