Why is deleting (or reading) files not counted as IO-Wait in top? - Kernel

This is a discussion on Why is deleting (or reading) files not counted as IO-Wait in top? - Kernel ; Hi Currently i'm deleting about 500.000 files on a XFS-filesystem which takes a few minutes, as i had a top open i saw that 'wa' is shown as 0.0% (Nothing else running currently) and everything except 'id' is near the ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Why is deleting (or reading) files not counted as IO-Wait in top?

  1. Why is deleting (or reading) files not counted as IO-Wait in top?

    Hi


    Currently i'm deleting about 500.000 files on a XFS-filesystem which
    takes a few minutes, as i had a top open i saw that 'wa' is shown as
    0.0% (Nothing else running currently) and everything except 'id' is near
    the bottom too. Kernel is 2.6.23.11.

    So, as 'rm -rf' is essentially a IO (or seek, to be more correct)-bound
    task, shouldn't that count as "Waiting for IO"?

    The man-page of top says:
    'Amount of time the CPU has been waiting for I/O to complete.'

    But AFAICT wa only seams to be (ac)counted for writing and not for
    reading. I come to that conclusion because, when i fire 'sync' i can see
    some percent wa for a few seconds.




    Bis denn

    --
    Real Programmers consider "what you see is what you get" to be just as
    bad a concept in Text Editors as it is in women. No, the Real Programmer
    wants a "you asked for it, you got it" text editor -- complicated,
    cryptic, powerful, unforgiving, dangerous.

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

  2. Re: Why is deleting (or reading) files not counted as IO-Wait in top?

    On Wednesday, 2 January 2008 21:35:03 Matthias Schniedermeyer wrote:
    > Hi
    >
    >
    > Currently i'm deleting about 500.000 files on a XFS-filesystem which
    > takes a few minutes, as i had a top open i saw that 'wa' is shown as
    > 0.0% (Nothing else running currently) and everything except 'id' is near
    > the bottom too. Kernel is 2.6.23.11.
    >
    > So, as 'rm -rf' is essentially a IO (or seek, to be more correct)-bound
    > task, shouldn't that count as "Waiting for IO"?
    >
    > The man-page of top says:
    > 'Amount of time the CPU has been waiting for I/O to complete.'
    >
    > But AFAICT wa only seams to be (ac)counted for writing and not for
    > reading. I come to that conclusion because, when i fire 'sync' i can see
    > some percent wa for a few seconds.
    >
    >
    >
    >
    > Bis denn
    >



    The IOWAIT time is the IDLE time that was spent waiting
    for I/O. (meaning that there were no tasks running, but some were waiting on I/O)

    Thus if you have another task that is not I/O bound, it can run in that time,
    and ideally, you shouldn't notice any I/O slowdown, but the iowait time will decrease.

    It wasn't the case before CFS introduction. I did few tests that showed almost 50% slowdown
    when running another task in that iowait time.
    It is not longer a problem with CFS.


    Regards,
    Maxim Levitsky
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: Why is deleting (or reading) files not counted as IO-Wait in top?

    On 03.01.2008 02:16, Maxim Levitsky wrote:
    > On Wednesday, 2 January 2008 21:35:03 Matthias Schniedermeyer wrote:
    > > Hi
    > >
    > >
    > > Currently i'm deleting about 500.000 files on a XFS-filesystem which
    > > takes a few minutes, as i had a top open i saw that 'wa' is shown as
    > > 0.0% (Nothing else running currently) and everything except 'id' is near
    > > the bottom too. Kernel is 2.6.23.11.
    > >
    > > So, as 'rm -rf' is essentially a IO (or seek, to be more correct)-bound
    > > task, shouldn't that count as "Waiting for IO"?
    > >
    > > The man-page of top says:
    > > 'Amount of time the CPU has been waiting for I/O to complete.'
    > >
    > > But AFAICT wa only seams to be (ac)counted for writing and not for
    > > reading. I come to that conclusion because, when i fire 'sync' i can see
    > > some percent wa for a few seconds.

    >
    > The IOWAIT time is the IDLE time that was spent waiting
    > for I/O. (meaning that there were no tasks running, but some were waiting on I/O)
    >
    > Thus if you have another task that is not I/O bound, it can run in that time,
    > and ideally, you shouldn't notice any I/O slowdown, but the iowait time will decrease.
    >
    > It wasn't the case before CFS introduction. I did few tests that showed almost 50% slowdown
    > when running another task in that iowait time.
    > It is not longer a problem with CFS.


    I can understand that, but in my case nothing else was running, so i
    would expect about 46%-50% wa (Dual Core Processor).




    Bis denn

    --
    Real Programmers consider "what you see is what you get" to be just as
    bad a concept in Text Editors as it is in women. No, the Real Programmer
    wants a "you asked for it, you got it" text editor -- complicated,
    cryptic, powerful, unforgiving, dangerous.

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

  4. Re: Why is deleting (or reading) files not counted as IO-Wait in top?

    On Wed, 2 Jan 2008 20:35:03 +0100 Matthias Schniedermeyer wrote:

    > Hi
    >
    >
    > Currently i'm deleting about 500.000 files on a XFS-filesystem which
    > takes a few minutes, as i had a top open i saw that 'wa' is shown as
    > 0.0% (Nothing else running currently) and everything except 'id' is near
    > the bottom too. Kernel is 2.6.23.11.
    >
    > So, as 'rm -rf' is essentially a IO (or seek, to be more correct)-bound
    > task, shouldn't that count as "Waiting for IO"?
    >
    > The man-page of top says:
    > 'Amount of time the CPU has been waiting for I/O to complete.'
    >
    > But AFAICT wa only seams to be (ac)counted for writing and not for
    > reading. I come to that conclusion because, when i fire 'sync' i can see
    > some percent wa for a few seconds.
    >


    Yes, you would absolutely expect `rm' to be stuck in D state and
    contributing to both load average and io-wait in this situation.

    I'd think that either XFS is playing games (and it'd take some pretty
    inventive games to do this) or your observations are in error.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: Why is deleting (or reading) files not counted as IO-Wait in top?

    On 05.01.2008 01:31, Andrew Morton wrote:
    > On Wed, 2 Jan 2008 20:35:03 +0100 Matthias Schniedermeyer wrote:
    >
    > > Hi
    > >
    > >
    > > Currently i'm deleting about 500.000 files on a XFS-filesystem which
    > > takes a few minutes, as i had a top open i saw that 'wa' is shown as
    > > 0.0% (Nothing else running currently) and everything except 'id' is near
    > > the bottom too. Kernel is 2.6.23.11.
    > >
    > > So, as 'rm -rf' is essentially a IO (or seek, to be more correct)-bound
    > > task, shouldn't that count as "Waiting for IO"?
    > >
    > > The man-page of top says:
    > > 'Amount of time the CPU has been waiting for I/O to complete.'
    > >
    > > But AFAICT wa only seams to be (ac)counted for writing and not for
    > > reading. I come to that conclusion because, when i fire 'sync' i can see
    > > some percent wa for a few seconds.
    > >

    >
    > Yes, you would absolutely expect `rm' to be stuck in D state and
    > contributing to both load average and io-wait in this situation.
    >
    > I'd think that either XFS is playing games (and it'd take some pretty
    > inventive games to do this) or your observations are in error.


    I don't think that i could do much wrong(tm).

    rm -rf (Took >30 minutes to delete)
    Everything else was sleeping at the time.

    The sleeping processes are the usual handful of about 200 processes, you
    have laying around today. 47 kernel threads, another about 40 or so
    demons, and the rest >100 processes was my KDE-Session (mostly
    'konsole's with bashes inside) with Iceweasel (Firefox) as sugar on top.
    But as i said, there weren't doing anything at all, 'us' peaked at about
    1-1.4 when i watched top.





    Bis denn

    --
    Real Programmers consider "what you see is what you get" to be just as
    bad a concept in Text Editors as it is in women. No, the Real Programmer
    wants a "you asked for it, you got it" text editor -- complicated,
    cryptic, powerful, unforgiving, dangerous.

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

  6. Re: Why is deleting (or reading) files not counted as IO-Wait in top?

    On Wed, Jan 02, 2008 at 08:35:03PM +0100, Matthias Schniedermeyer wrote:
    > Hi
    >
    >
    > Currently i'm deleting about 500.000 files on a XFS-filesystem which
    > takes a few minutes, as i had a top open i saw that 'wa' is shown as
    > 0.0% (Nothing else running currently) and everything except 'id' is near
    > the bottom too. Kernel is 2.6.23.11.


    Simply because the only I/O that XFS does during a delete is
    to the log and the log does async I/O and hence the process
    never blocks in I/O.

    Instead, it blocks in a far more complex space reservation that
    may or may not be related to I/O wait....

    > So, as 'rm -rf' is essentially a IO (or seek, to be more correct)-bound
    > task, shouldn't that count as "Waiting for IO"?


    rm -rf is not seek bound on XFS - it's generally determined by
    the sequential write speed of the block device or how fast your
    CPU is....

    > The man-page of top says:
    > 'Amount of time the CPU has been waiting for I/O to complete.'


    Async I/O means that typically your CPU does not get held up
    waiting for I/O to complete....

    Cheers,

    Dave.
    --
    Dave Chinner
    Principal Engineer
    SGI Australian Software Group
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/