All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Daniel Pittman <daniel@rimspace.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Delaying writes to disk when there's no need
Date: Mon, 31 Mar 2003 17:45:43 -0800	[thread overview]
Message-ID: <20030331174543.374030ba.akpm@digeo.com> (raw)
In-Reply-To: <87pto7f1ad.fsf@enki.rimspace.net>

Daniel Pittman <daniel@rimspace.net> wrote:
>
> > What do you think?
> 
> I will apply the patch and test later today.  This, however, looks like
> a *really* good thing to me.

I think so too.

A possible enhancement is to only do the flush if the backing queue is not
write-congested.  So the syscall will very probably be async.  If the queue
is write congested then it's a sure bet that someone else is saturating the
disk ayway.  We don't want to block in that case.


 25-akpm/include/linux/fs.h |    1 +
 25-akpm/mm/fadvise.c       |    2 ++
 25-akpm/mm/filemap.c       |   18 ++++++++++++++++--
 3 files changed, 19 insertions(+), 2 deletions(-)

diff -puN include/linux/fs.h~fadvise-flush-data include/linux/fs.h
--- 25/include/linux/fs.h~fadvise-flush-data	Mon Mar 31 17:03:39 2003
+++ 25-akpm/include/linux/fs.h	Mon Mar 31 17:43:45 2003
@@ -1112,6 +1112,7 @@ unsigned long invalidate_inode_pages(str
 extern void invalidate_inode_pages2(struct address_space *mapping);
 extern void write_inode_now(struct inode *, int);
 extern int filemap_fdatawrite(struct address_space *);
+extern int filemap_flush(struct address_space *);
 extern int filemap_fdatawait(struct address_space *);
 extern void sync_supers(void);
 extern void sync_filesystems(int wait);
diff -puN mm/fadvise.c~fadvise-flush-data mm/fadvise.c
--- 25/mm/fadvise.c~fadvise-flush-data	Mon Mar 31 17:03:39 2003
+++ 25-akpm/mm/fadvise.c	Mon Mar 31 17:44:49 2003
@@ -61,6 +61,8 @@ long sys_fadvise64(int fd, loff_t offset
 			ret = 0;
 		break;
 	case POSIX_FADV_DONTNEED:
+		if (!bdi_write_congested(mapping->backing_dev_info))
+			filemap_flush(mapping);
 		invalidate_mapping_pages(mapping, offset >> PAGE_CACHE_SHIFT,
 				(len >> PAGE_CACHE_SHIFT) + 1);
 		break;
diff -puN mm/filemap.c~fadvise-flush-data mm/filemap.c
--- 25/mm/filemap.c~fadvise-flush-data	Mon Mar 31 17:03:39 2003
+++ 25-akpm/mm/filemap.c	Mon Mar 31 17:03:39 2003
@@ -122,11 +122,11 @@ static inline int sync_page(struct page 
  * if a dirty page/buffer is encountered, it must be waited upon, and not just
  * skipped over.
  */
-int filemap_fdatawrite(struct address_space *mapping)
+static int __filemap_fdatawrite(struct address_space *mapping, int sync_mode)
 {
 	int ret;
 	struct writeback_control wbc = {
-		.sync_mode = WB_SYNC_ALL,
+		.sync_mode = sync_mode,
 		.nr_to_write = mapping->nrpages * 2,
 	};
 
@@ -140,6 +140,20 @@ int filemap_fdatawrite(struct address_sp
 	return ret;
 }
 
+int filemap_fdatawrite(struct address_space *mapping)
+{
+	return __filemap_fdatawrite(mapping, WB_SYNC_ALL);
+}
+
+/*
+ * This is a mostly non-blocking flush.  Not suitable for data-integrity
+ * purposes.
+ */
+int filemap_flush(struct address_space *mapping)
+{
+	return __filemap_fdatawrite(mapping, WB_SYNC_NONE);
+}
+
 /**
  * filemap_fdatawait - walk the list of locked pages of the given address
  *                     space and wait for all of them.

_


  reply	other threads:[~2003-04-01  1:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-26 20:31 Delaying writes to disk when there's no need Erik Hensema
2003-03-27  9:06 ` Helge Hafting
2003-03-27 11:22   ` Erik Hensema
2003-03-28 23:12 ` Pavel Machek
2003-03-31 12:00   ` Erik Hensema
2003-03-31 13:42     ` Helge Hafting
2003-03-31 14:45       ` Oliver Neukum
2003-03-31 22:02       ` Nick Piggin
2003-03-31 22:22         ` Chris Friesen
2003-03-31 22:35           ` Nick Piggin
2003-03-31 22:51             ` John Bradford
2003-03-31 22:58               ` Nick Piggin
2003-03-31 22:45         ` Andrew Morton
2003-03-31 23:03           ` Nick Piggin
2003-03-31 23:32           ` Ingo Oeser
2003-04-01  0:02             ` Andrew Morton
2003-04-01  0:43           ` Daniel Pittman
2003-04-01  1:09             ` Andrew Morton
2003-04-01  1:34               ` Daniel Pittman
2003-04-01  1:45                 ` Andrew Morton [this message]
     [not found]               ` <3E88EB3D.6020409@cyberone.com.au>
2003-04-01  1:39                 ` Andrew Morton
     [not found] <20030326204012$188c@gated-at.bofh.it>
     [not found] ` <20030327091007$22a5@gated-at.bofh.it>
     [not found]   ` <20030327113014$37b4@gated-at.bofh.it>
2003-03-28 10:18     ` Tim Connors
2003-03-30 17:38       ` Helge Hafting

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=20030331174543.374030ba.akpm@digeo.com \
    --to=akpm@digeo.com \
    --cc=daniel@rimspace.net \
    --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.