The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: imp@bsdimp.com (Warner Losh)
Subject: [TUHS] UNIX on S/370
Date: Mon, 20 Nov 2017 22:14:41 -0700	[thread overview]
Message-ID: <CANCZdfpfZoJS3hx2aCdjX0rYwKazscTykdy4ku8Vkm7-wq8xpA@mail.gmail.com> (raw)
In-Reply-To: <20171121035112.GC9093@mcvoy.com>

On Nov 20, 2017 8:51 PM, "Larry McVoy" <lm at mcvoy.com> wrote:

Actually, how common was that?  I know at SGI we did that with O_DIRECT
on files (and just automatically on the way for in networking and page
flipped on the way out).  But it was a pile of work, you had to lock
all the pages so that the pageout daemon didn't page them out, etc.

So under what circumstances would Unix do DMA to/from user buffers
rather than bcopy it?


I assume you aren't talking about things like mmap where you can't really
bcopy it...

At Fusion I/O we had hooks into our PCIe flash card driver that would do
DMA directly into user buffers (since we wanted IOPS and any extra copies
got in the way of that). We also played fun tricks with 'extended I/O
primitives' that were implemented with ioctls, but still did I/O to/from
user buffers. This was so we could construct 1 transaction for what's
basically an atomic writev (more complicated than that, because the atomic
operation also supported delete/trim operations at the same time). This was
to simplify checkpointing since it was an all or nothing thing: if we
couldn't do it, or the system crashed in the middle, the transaction never
happened. There were other, more extended I/O operations that involved read
as well that were kinda crazy, but useful for a market segment we did well
in. Also likely no the sort of thing that you were thinking about, but it
was a novel use of DMA to user buffers.

Warner

On Mon, Nov 20, 2017 at 10:15:58PM -0500, Ron Natalie wrote:
> That's a common optimization, but the only real requirement in the UNIX
> kernel is the raw I/O bypasses the kernel buffer cache.
>
>
> -----Original Message-----
> From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Noel Chiappa
> Sent: Monday, November 20, 2017 9:57 PM
> To: tuhs at tuhs.org
> Cc: jnc at mercury.lcs.mit.edu
> Subject: Re: [TUHS] UNIX on S/370
>
>     > From: Larry McVoy
>
>     > So tape I can see being more weird, but isn't raw disk just "don't
put
>     > it in buffer cache"?
>
> One machines/controllers which are capable of it, with raw devices DMA
> happens directly into the buffers in the process (which obviously has to
be
> resident while the I/O is happening).
>
>     Noel

--
---
Larry McVoy                  lm at mcvoy.com
http://www.mcvoy.com/lm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/92117e5a/attachment.html>


  reply	other threads:[~2017-11-21  5:14 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-21  2:56 Noel Chiappa
2017-11-21  3:15 ` Ron Natalie
2017-11-21  3:51   ` Larry McVoy
2017-11-21  5:14     ` Warner Losh [this message]
2017-11-21  5:20       ` Larry McVoy
  -- strict thread matches above, loose matches on Subject: below --
2017-11-22 15:38 Noel Chiappa
2017-11-28  0:13 ` Kevin Bowling
2017-11-20 16:05 Noel Chiappa
2017-11-20 16:37 ` Clem Cole
2017-11-20 16:47   ` Charles H Sauer
2017-11-20 17:44     ` Toby Thain
2017-11-20 19:07 ` Paul Winalski
2017-11-20 19:10   ` Larry McVoy
2017-11-20 19:36     ` Warner Losh
2017-11-20 19:36       ` Larry McVoy
2017-11-20 19:39         ` Larry McVoy
2017-11-20 19:56     ` Arthur Krewat
2017-11-20 19:59       ` Larry McVoy
2017-11-20 19:27   ` arnold
2017-11-20 19:29     ` Larry McVoy
2017-11-20 22:56       ` Michael Parson
2017-11-20 23:23         ` Larry McVoy
2017-11-20  0:57 Nemo
2017-11-20  1:01 ` Ronald Natalie
2017-11-20  1:06 ` Dave Horsfall
2017-11-20  3:50 ` arnold
2017-11-20 15:23   ` Clem Cole
2017-11-20 16:03     ` ron minnich
2017-11-20 16:31       ` Clem Cole
2017-11-20 19:44         ` Paul Winalski
2017-11-20 19:56           ` Larry McVoy
2017-11-20 23:43             ` Ron Natalie
2017-11-20 23:45               ` Larry McVoy
2017-11-20 23:49                 ` Ron Natalie
     [not found]                 ` <CAC20D2N=aBhdON1YqHH57ZG-TmC62yWGF4_=HK5Gp2XwdbHkyQ@mail.gmail.com>
2017-11-21  2:41                   ` Larry McVoy
2017-11-29 22:42                     ` Dave Horsfall
2017-11-29 22:55                       ` ron minnich
2017-11-21  1:15     ` Ron Natalie
2017-11-21  3:29       ` Grant Taylor
2017-11-21  3:40         ` Ron Natalie
2017-11-21  3:46           ` Grant Taylor
2017-11-21  8:09             ` arnold
2017-11-21 16:49             ` Paul Winalski
2017-11-21  4:34           ` Clem cole
2017-11-21  5:42             ` Grant Taylor
2017-11-21 12:00               ` Ron Natalie
2017-11-21 13:51                 ` Clem Cole
2017-11-21 14:59                   ` Larry McVoy
2017-11-21 17:06                     ` Clem Cole
2017-11-21 17:23                       ` Clem Cole
2017-11-21 18:29                         ` Larry McVoy
2017-11-21 19:10                           ` Clem Cole
2017-11-21 15:40                   ` Ron Natalie
2017-11-21 15:45                     ` Larry McVoy
2017-11-21 13:24               ` Clem Cole
2017-11-22  1:33 ` Kevin Bowling
2017-11-22  6:35   ` Wesley Parish
2017-11-22  9:38     ` Kevin Bowling
2017-11-22 13:40       ` Clem Cole
2017-11-22 14:09         ` Ron Natalie
2017-11-22 13:51     ` Clem Cole
2017-11-22 14:04       ` Ron Natalie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANCZdfpfZoJS3hx2aCdjX0rYwKazscTykdy4ku8Vkm7-wq8xpA@mail.gmail.com \
    --to=imp@bsdimp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).