linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@inetnebr.com (Eric W. Biederman)
To: Bernhard Heidegger <bheide@hyperwave.com>
Cc: 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: 27 Aug 1998 20:03:34 -0500	[thread overview]
Message-ID: <m1d89lex3t.fsf@flinx.npwt.net> (raw)
In-Reply-To: Bernhard Heidegger's message of Thu, 27 Aug 1998 14:43:31 +0200 (MET DST)

>>>>> "BH" == Bernhard Heidegger <bheide@hyperwave.com> writes:

>>>>> ">" == Zlatko Calusic <Zlatko.Calusic@CARNet.hr> writes:
>>> Bernhard Heidegger <bheide@hyperwave.com> writes:
>>> >>>>> ">" == Zlatko Calusic <Zlatko.Calusic@CARNet.hr> writes:
>>> 
>>> >> "H. Peter Anvin" <hpa@transmeta.com> writes:
>>> >> > 
>>> >> > bdflush yes, but update is not obsolete.
>>> >> > 
>>> >> > It is still needed if you want to make sure data (and metadata)
>>> >> > eventually gets written to disk.
>>> >> > 
>>> >> > Of course, you can run without update, but then don't bother if you
>>> >> > lose file in system crash, even if you edited it and saved it few
>>> >> > hours ago. :)
>>> >> > 
>>> >> > Update is very important if you have lots of RAM in your computer.
>>> >> > 
>>> >> 
>>> >> Oh.  I guess my next question then is "why", as why can't this be done
>>> >> by kflushd as well?
>>> >> 
>>> 
>>> >> To tell you the truth, I'm not sure why, these days.
>>> 
>>> >> I thought it was done this way (update running in userspace) so to
>>> >> have control how often buffers get flushed. But, I believe bdflush
>>> >> program had this functionality, and it is long gone (as you correctly
>>> >> noticed).
>>> 
>>> IMHO, update/bdflush (in user space) calls sys_bdflush regularly. This
>>> function (fs/buffer.c) calls sync_old_buffers() which itself sync_supers
>>> and sync_inodes before it goes through the dirty buffer lust (to write
>>> some dirty buffers); the kflushd only writes some dirty buffers dependent
>>> on the sysctl parameters.
>>> If I'm wrong, please feel free to correct me!
>>> 

>>> You are not wrong.

>>> Update flushes metadata blocks every 5 seconds, and data block every
>>> 30 seconds.

BH> My version of update (something around Slakware 3.4) does the following:
BH> 1.) calls bdflush(1,0) (fs/buffer.c:sys_bdflush) which will call
BH>     sync_old_buffers() and return
BH> 2.) only if the bdflush(1,0) fails (it returns < 0) it returns to the
BH>     old behavior of sync()ing every 30 seconds

BH> But case 2) should only happen on really old kernels; on newer kernels
BH> (I'm using 2.0.34) the bdflush() should never fail.

BH> But as I told, sync_old_buffers() do:
BH> 1.) sync_supers(0)
BH> 2.) sync_inodes(0)
BH> 3.) go through dirty buffer list and may flush some buffers

BH> Conclusion: the meta data get synced every 5 seconds and some buffers may
BH> be flushed.

>>> Questions is why can't this functionality be integrated in the kernel, 
>>> so we don't have to run yet another daemon?

We can do this in kernel thread but I don't see the win.

BH> Good question, but I've another one: IMHO sync_old_buffers (especially
BH> the for loop) do similar things as the kflushd. Why??

kflushd removes buffers only when we are low on memory, and unconditionally.

bdflush lets buffers sit for 30 seconds and every 5 seconds it checks
for buffers that are at least 30 seconds old and flushes them.

bdflush does most of the work.

BH> Is it possible to reduce the sync_old_buffers() routine to soemthing like:

No.  Major performance problem.

Eric
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

  reply	other threads:[~1998-08-28  2:08 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 ` 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 [this message]
1998-08-28  9:09           ` Bernhard Heidegger
1998-08-28 13:14             ` Eric W. Biederman
1998-08-28 16:03               ` Bernhard Heidegger
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=m1d89lex3t.fsf@flinx.npwt.net \
    --to=ebiederm@inetnebr.com \
    --cc=Zlatko.Calusic@CARNet.hr \
    --cc=bheide@hyperwave.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox