From: Bernhard Heidegger <bheide@hyperwave.com>
To: "Eric W. Biederman" <ebiederm@inetnebr.com>
Cc: Bernhard Heidegger <bheide@hyperwave.com>,
Zlatko.Calusic@CARNet.hr, "H. Peter Anvin" <hpa@transmeta.com>,
Linux Kernel List <linux-kernel@vger.rutgers.edu>,
Linux-MM List <linux-mm@kvack.org>
Subject: Re: [PATCH] 498+ days uptime
Date: Fri, 28 Aug 1998 18:03:17 +0200 (MET DST) [thread overview]
Message-ID: <199808281603.SAA05389@hwal02.hyperwave.com> (raw)
In-Reply-To: <m1btp5dz8u.fsf@flinx.npwt.net>
>>>>> ">" == Eric W Biederman <ebiederm@inetnebr.com> writes:
>>>> No. Major performance problem.
BH> Why?
BH> Imagine an application which has most of the (index) file pages in memory
BH> and many of the pages are dirty. bdflush will flush the pages regularly,
BH> but the pages will get dirty immediately again.
BH> If you can be sure, that the power cannot fail the performance should be
BH> much better without bdflush, because kflushd has to write pages only if
BH> the system is running low on memory...
>> The performance improvement comes when looking for free memory. In
>> most cases bdflush's slow but steady writing of pages keeps buffers
>> clean. When the application wants more memory with bdflush in the
>> background unsually the pages it needs will be clean (because the I/O
>> started before the application needed it), so they can just be dropped
>> out of memory. Relying on kflushd means nothing is written until an
>> application needs the memory and then it must wait until something is
>> written to disk, which is much slower.
>> Further
>> a) garanteeing no power failure is hard.
Use and UPS and regularly flush/sync the primary data to disk from
the application
>> b) generally there is so much data on the disk you must write it
>> sometime, because you can't hold it all in memory.
only a question of how much RAM you can put in your PC
>> c) I have trouble imagining a case where a small file would be rewritten
>> continually.
Not really small, but a database application may use btree based indexes,
where many blocks will get dirty when inserting/deleting data. If you flush
the dirty buffers and the next insertion dirty the same buffer(s) you have
lost performance (Note: the btree based indexes are secondary data; you
can rebuild it from scratch if the system fails)
Bernhard
get my pgp key from a public keyserver (keyID=0x62446355)
-----------------------------------------------------------------------------
Bernhard Heidegger bheide@hyperwave.com
Hyperwave Software Research & Development
Schloegelgasse 9/1, A-8010 Graz
Voice: ++43/316/820918-25 Fax: ++43/316/820918-99
-----------------------------------------------------------------------------
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
next prev parent reply other threads:[~1998-08-28 16:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <199808262153.OAA13651@cesium.transmeta.com>
1998-08-26 22:49 ` [PATCH] 498+ days uptime Zlatko Calusic
1998-08-27 12:07 ` Bernhard Heidegger
1998-08-27 12:21 ` Zlatko Calusic
1998-08-27 12:43 ` Bernhard Heidegger
1998-08-28 1:03 ` Eric W. Biederman
1998-08-28 9:09 ` Bernhard Heidegger
1998-08-28 13:14 ` Eric W. Biederman
1998-08-28 16:03 ` Bernhard Heidegger [this message]
1998-08-28 22:03 ` Zlatko Calusic
1998-08-31 8:32 ` Bernhard Heidegger
1998-08-28 21:47 ` Zlatko Calusic
1998-08-28 21:36 ` Zlatko Calusic
1998-08-28 21:32 ` Zlatko Calusic
1998-08-28 9:35 ` Stephen C. Tweedie
1998-08-28 22:16 ` Zlatko Calusic
1998-08-30 15:10 ` Stephen C. Tweedie
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=199808281603.SAA05389@hwal02.hyperwave.com \
--to=bheide@hyperwave.com \
--cc=Zlatko.Calusic@CARNet.hr \
--cc=ebiederm@inetnebr.com \
--cc=hpa@transmeta.com \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.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.