From: gfiala@s.netic.de
To: linux-kernel@vger.kernel.org
Subject: Re: large files unnecessary trashing filesystem cache?
Date: Wed, 19 Oct 2005 13:06:51 +0200 [thread overview]
Message-ID: <1129720011.435628cb150f5@webmail.LF.net> (raw)
In-Reply-To: <Pine.LNX.4.58.0510190902210.2281@be1.lrz>
Zitat von Bodo Eggert <7eggert@gmx.de>:
> You can alyo cat a big file into /dev/null. I made those examples in order
> to demonstrate the problem with using O_DIRECT.
O_DIRECT has to much impact at the mentioned "vdr" due to unwanted side effects
either.
>
> OTOH, I don't realtime stuff on my computer, so I'm not really affected,
> but I'll try to show it anyway.
>
> > > Changing a few programs will only partly cover the problems.
> > >
> > > I guess the solution would be using random cache eviction rather than
> > > a FIFO. I never took a look the cache mechanism, so I may very well be
> > > wrong here.
> >
> > Read-only pages should be re-cycled really easily & quickly. I can't
> > belive read-only pages are causing you all the trouble.
>
> Just a q&d test:
>
> $ time ls -l $DIR > /dev/null
> real 0m0.442s
> user 0m0.008s
> sys 0m0.024s
>
> $ time ls -l $DIR > /dev/null
> real 0m0.077s
> user 0m0.008s
> sys 0m0.008s
>
> cat $BIGFILES_1.5GB > /Dev/null
>
> $ time ls -l $DIR > /dev/null
> real 0m0.270s
> user 0m0.008s
> sys 0m0.008s
>
> $ time ls -l $DIR > /dev/null
> real 0m0.078s
> user 0m0.004s
> sys 0m0.004s
>
>
Thanks for pointing this out - this clearly shows the effect.
Now consider a mildly loaded multitasking environment running X, some services,
window-manager, email, maybe some databases and a streaming video-application
at once (so does mine) - the video-file will have unwanted impact on all the
other applications - leading to unnecessary reloads of lots of files, inodes
etc.
next prev parent reply other threads:[~2005-10-19 11:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4Z5WG-1iM-19@gated-at.bofh.it>
[not found] ` <4Z6zs-27l-39@gated-at.bofh.it>
2005-10-18 21:58 ` large files unnecessary trashing filesystem cache? Bodo Eggert
2005-10-18 23:05 ` Badari Pulavarty
2005-10-19 0:20 ` David Lang
2005-10-19 0:33 ` Fawad Lateef
2005-10-19 1:42 ` Bernd Eckenfels
2005-10-19 7:23 ` Bodo Eggert
2005-10-19 11:06 ` gfiala [this message]
2005-10-19 13:43 ` Avi Kivity
2005-10-18 20:01 Guido Fiala
2005-10-18 20:48 ` Badari Pulavarty
2005-10-20 15:23 ` Guido Fiala
2005-10-19 3:02 ` Andrew James Wade
2005-10-19 4:37 ` Andrew Morton
2005-10-19 5:45 ` Andrew James Wade
2005-10-19 11:01 ` gfiala
2005-10-19 11:10 ` gfiala
2005-10-19 15:54 ` Ingo Oeser
2005-10-19 19:49 ` Andrew Morton
2005-10-19 22:26 ` Paul Jackson
2005-10-20 6:28 ` Ingo Oeser
2005-10-19 4:10 ` Lee Revell
2005-10-19 15:43 ` Badari Pulavarty
2005-10-19 17:58 ` Guido Fiala
2005-10-19 18:43 ` Kyle Moffett
2005-10-19 18:52 ` Guido Fiala
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=1129720011.435628cb150f5@webmail.LF.net \
--to=gfiala@s.netic.de \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.