lkml.org 
[lkml]   [1998]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: PATCH: Raw device IO for 2.1.131
    Hi,

    On Sat, 12 Dec 1998 14:09:48 -0800 (PST), Linus Torvalds
    <torvalds@transmeta.com> said:

    > Quite frankly, nobody has EVER given me a reason that makes any kind of
    > sense at all for supporting raw devices in any other way than we already
    > do. Nobody sane uses a disk without a filesystem, and the insane people
    > that do I feel we can and should ignore. Insanity has a way of dying off
    > over time, when Darvin starts to look into it.

    Don't read too much into the implementation's restriction to raw
    devices: the core rw_raw_io as implemented already takes, and uses, an
    optional bmap() argument, and the _only_ thing missing for a full
    ext2fs O_DIRECT right now is cache coherency.

    The aim here is O_DIRECT, for filesystem access and not just for raw
    devices. The block device interface just happens to be sufficiently
    simple to be worth testing first.

    > I've also become almost completely uninterested in zero-copy schemes. They
    > make for great benchmarks, but have little relevance to anything else. You
    > have two cases:
    > - sendfile() like copying things around. We want to do zero-copy here,
    > but it's easy because everything is already in kernel space.
    > - real work. If zero-copy makes a real difference, you'd better buy a new
    > computer, because your memory subsystem is too slow. Either you're IO
    > bound or you aren't, and if you're IO bound and your memory is slower
    > than your IO then it's not something the OS should do all that much
    > about. And if you aren't IO-bound, then the whole discussion is moot.

    I really don't think it's an issue of memory bandwidth: it's about CPU
    utilisation, and to some extent about cache trashing. Right now, on
    this P200, reading from /dev/sda1 (a paltry 5MB/sec over ncr scsi)
    takes 18% system-time cpu utilisation, and reading from /dev/rsda1
    takes 4%. That's a heck of a lot of cpu time which my database
    application could be using for something more useful. Large
    data-shuffling applications _are_ often cpu bound, or people wouldn't
    be running them on 4-way SMP boxes.

    --Stephen

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:46    [W:0.021 / U:2.324 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site