All of lore.kernel.org
 help / color / mirror / Atom feed
From: Badari Pulavarty <pbadari@gmail.com>
To: 7eggert@gmx.de
Cc: Guido Fiala <gfiala@s.netic.de>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: large files unnecessary trashing filesystem cache?
Date: Tue, 18 Oct 2005 16:05:53 -0700	[thread overview]
Message-ID: <1129676753.23632.90.camel@localhost.localdomain> (raw)
In-Reply-To: <E1ERzTq-0001IA-Ba@be1.lrz>

On Tue, 2005-10-18 at 23:58 +0200, Bodo Eggert wrote:
> Badari Pulavarty <pbadari@gmail.com> wrote:
> > On Tue, 2005-10-18 at 22:01 +0200, Guido Fiala wrote:
> 
> [large files trash cache]
> 
> > Is there a reason why those applications couldn't use O_DIRECT ?
> 
> The cache trashing will affect all programs handling large files:
> 
> mkisofs * > iso
> dd < /dev/hdx42 | gzip > imagefile
> perl -pe's/filenamea/filenameb/' < iso | cdrecord - # <- never tried
> 

Are these examples which demonstrate the thrashing problem.
Few product (database) groups here are trying to get me to 
work on a solution before demonstrating the problem. They 
also claim exactly what you are saying. They want a control
on how many pages (per process or per file or per filesystem
or system wide) you can have in filesystem cache.

Thats why I am pressing to find out the real issue behind this.
If you have a demonstratable testcase, please let me know.
I will be happy to take a look.


> 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.


Thanks,
Badari


  reply	other threads:[~2005-10-18 23: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 [this message]
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
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=1129676753.23632.90.camel@localhost.localdomain \
    --to=pbadari@gmail.com \
    --cc=7eggert@gmx.de \
    --cc=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.