lkml.org 
[lkml]   [1996]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: "raw" block devices?
   Date: 	Fri, 18 Oct 1996 01:57:52 +1000 (EST)
From: David Monro <davidm@fuzzbox.psrg.cs.usyd.edu.au>

1) Messing with the raw device doesn't go through the buffer cache,
so programs which basically scan a large device (eg fsck) don't trash
the cache. Seems reasonable. Does e2fsck have some nifty way of not
trashing cache currently? Also this allows eg database systems to be
given a slice of disk which they are in complete control of, and can
maybe manage better than the normal buffering (known access patterns
etc).

When you're running e2fsck at the beginning of the boot sequence, there
really isn't much cache to trash. :-)

2) Because of the above, it should be possible to get data straight from the
device into user memory without any copying. This should be a big win eg for
the above mentioned database system. Actually it should be possible to
do this anyway using copy-on-write and having the kernel copy the page only
if it is modified by the program (using the same phys memory in both the
cache and the user space). Currently I believe we don't do this;
correct me if I am wrong.

Actually, if you're using mmap, you *can* get the data into the user
memory without doing any copying. That's how the new memory management
system works.

Eventually, it should be possible to do the same with read's, either
filesystem reads or reads from the device; there'll no doubt be
restrictions such as requiring that you read a full page, and that the
target buffer be page aligned, etc., but I know there are people who
were thinking about doing things like this for 2.1.

Similarly, you can play similar tricks for network writes; just DMA it
straight from user memory. One of the ways how the SGI gets truely
awesome web server benchmarks is by doing zero-copy disk reads from the
filesystem, and zero-copy network writes. All you need the CPU for is
to set up the DMA's, lock down the memory pages, and stay out of the
way. :-)

- Ted


\
 
 \ /
  Last update: 2005-03-22 13:37    [from the cache]
©2003-2011 Jasper Spaans