summaryrefslogtreecommitdiff
path: root/open_issues/resource_management_problems/io_accounting.mdwn
blob: 113b965a037b92cae7b521520e30cc865db4ba1e (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

IRC, freenode, #hurd, 2011-07-22

    <braunr> an interesting question i've had in mind for a few weeks now is
      I/O accounting
    <braunr> what *is* I/O on a microkernel based system ?
    <braunr> can any cross address space transfer be classified as I/O ?

IRC, freenode, #hurd, 2011-07-29

    < braunr> how does the hurd account I/O ?
    < youpi> I don't think it does
    < youpi> not an easy task, actually
    < youpi> since gnumach has no idea about it
    < braunr> yes
    < braunr> another centralization issue
    < braunr> does network access count as I/O on linux ?
    < youpi> no
    < braunr> not even nfs ?
    < youpi> else you'd get 100% for servers :)
    < braunr> right
    < youpi> nfs goes through vfs first
    < braunr> i'll rephrase my question
    < youpi> I'd need to check but I believe it can check nfs
    < braunr> does I/O accounting occur at the vfs level or block layer ?
    < youpi> I don't know, but I beleive vfs
    < youpi> (at least that's how I'd do it)
    < braunr> i don't have any more nfs box to test that :/
    < braunr> personally i'd do it at the block layer :)
    < youpi> well, both
    < youpi> so e2fsck can show up too
    < braunr> yes
    < youpi> it's just a matter of ref counting
    < youpi> apparently nfs doesn't account
    < youpi> find . -printf "" doesn't show up in waitio
    < braunr> good
    < youpi> well, depends on the point of view
    < youpi> as a user, you'd like to know whether your processes are stuck on
      i/o (be it disk or net)
    < braunr> this implies clearly defining what io is