All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: jamie@shareable.org, steve@chygwyn.com, zbr@ioremap.net,
	npiggin@suse.de, akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [patch] fs: improved handling of page and buffer IO errors
Date: Thu, 23 Oct 2008 07:48:04 -0600	[thread overview]
Message-ID: <20081023134804.GL26094@parisc-linux.org> (raw)
In-Reply-To: <E1Ksexg-0001Ng-8F@pomaz-ex.szeredi.hu>

On Wed, Oct 22, 2008 at 04:45:24PM +0200, Miklos Szeredi wrote:
> On Wed, 22 Oct 2008, Matthew Wilcox wrote:
> > remap_file_pages() only hurts if you map the same page more than once
> > (which is permitted, but again, I don't think anyone actually does
> > that).
> 
> This is getting very offtopic... but remap_file_pages() is just like
> MAP_FIXED, that the address at which a page is mapped is determined by
> the caller, not the kernel.  So coherency with other, independent
> mapping of the file is basically up to chance.

Oh, right, I see.

> Do we care?  I very much hope not.  Why do PA-RISC and friends care at
> all about mmap coherecy?  Is it real-world problem driven or just to
> be safe?

One reason to care is performance.  If two tasks have libc mapped
coherently, then the addresses will collide in the cache and they'll
use the same cachelines.  I don't know how much applications care about
correctness with mmap -- they certainly do with sysv shm.  I probably
knew about some applications that broke when I was working on this code --
back in 2002.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <matthew@wil.cx>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: jamie@shareable.org, steve@chygwyn.com, zbr@ioremap.net,
	npiggin@suse.de, akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [patch] fs: improved handling of page and buffer IO errors
Date: Thu, 23 Oct 2008 07:48:04 -0600	[thread overview]
Message-ID: <20081023134804.GL26094@parisc-linux.org> (raw)
In-Reply-To: <E1Ksexg-0001Ng-8F@pomaz-ex.szeredi.hu>

On Wed, Oct 22, 2008 at 04:45:24PM +0200, Miklos Szeredi wrote:
> On Wed, 22 Oct 2008, Matthew Wilcox wrote:
> > remap_file_pages() only hurts if you map the same page more than once
> > (which is permitted, but again, I don't think anyone actually does
> > that).
> 
> This is getting very offtopic... but remap_file_pages() is just like
> MAP_FIXED, that the address at which a page is mapped is determined by
> the caller, not the kernel.  So coherency with other, independent
> mapping of the file is basically up to chance.

Oh, right, I see.

> Do we care?  I very much hope not.  Why do PA-RISC and friends care at
> all about mmap coherecy?  Is it real-world problem driven or just to
> be safe?

One reason to care is performance.  If two tasks have libc mapped
coherently, then the addresses will collide in the cache and they'll
use the same cachelines.  I don't know how much applications care about
correctness with mmap -- they certainly do with sysv shm.  I probably
knew about some applications that broke when I was working on this code --
back in 2002.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-10-23 13:48 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-21 11:21 [patch] fs: improved handling of page and buffer IO errors Nick Piggin
2008-10-21 11:21 ` Nick Piggin
2008-10-21 12:52 ` Miklos Szeredi
2008-10-21 12:52   ` Miklos Szeredi
2008-10-21 12:59   ` steve
2008-10-21 12:59     ` steve
2008-10-21 13:14     ` Miklos Szeredi
2008-10-21 13:14       ` Miklos Szeredi
2008-10-21 13:38       ` steve
2008-10-21 13:38         ` steve
2008-10-21 14:32         ` Miklos Szeredi
2008-10-21 14:32           ` Miklos Szeredi
2008-10-21 15:09           ` steve
2008-10-21 15:09             ` steve
2008-10-21 16:13             ` Miklos Szeredi
2008-10-21 16:13               ` Miklos Szeredi
2008-10-22 12:51               ` Jamie Lokier
2008-10-22 12:51                 ` Jamie Lokier
2008-10-22 14:08                 ` Miklos Szeredi
2008-10-22 14:08                   ` Miklos Szeredi
2008-10-21 14:35         ` Evgeniy Polyakov
2008-10-21 14:35           ` Evgeniy Polyakov
2008-10-21 14:59           ` steve
2008-10-21 14:59             ` steve
2008-10-21 16:20             ` Miklos Szeredi
2008-10-21 16:20               ` Miklos Szeredi
2008-10-21 16:25               ` steve
2008-10-21 16:25                 ` steve
2008-10-21 16:28               ` Miklos Szeredi
2008-10-21 16:28                 ` Miklos Szeredi
2008-10-21 16:29                 ` Matthew Wilcox
2008-10-21 16:29                   ` Matthew Wilcox
2008-10-22 12:48                   ` Jamie Lokier
2008-10-22 12:48                     ` Jamie Lokier
2008-10-22 13:45                     ` Matthew Wilcox
2008-10-22 13:45                       ` Matthew Wilcox
2008-10-22 14:02                       ` Miklos Szeredi
2008-10-22 14:02                         ` Miklos Szeredi
2008-10-22 14:35                         ` Matthew Wilcox
2008-10-22 14:45                           ` Miklos Szeredi
2008-10-22 14:45                             ` Miklos Szeredi
2008-10-23 13:48                             ` Matthew Wilcox [this message]
2008-10-23 13:48                               ` Matthew Wilcox
2008-10-22 22:23     ` Mark Fasheh
2008-10-22 22:23       ` Mark Fasheh
2008-10-23  9:59       ` steve
2008-10-23  9:59         ` steve
2008-10-23 10:21         ` Nick Piggin
2008-10-23 10:21           ` Nick Piggin
2008-10-23 10:52           ` steve
2008-10-23 10:52             ` steve
2008-10-23 11:07             ` Nick Piggin
2008-10-23 11:07               ` Nick Piggin
2008-10-22 13:16   ` Nick Piggin
2008-10-22 13:16     ` Nick Piggin
2008-10-22 20:09     ` Miklos Szeredi
2008-10-22 20:09       ` Miklos Szeredi
2008-10-21 16:16 ` Andi Kleen
2008-10-21 16:16   ` Andi Kleen
2008-10-21 16:30   ` steve
2008-10-21 16:30     ` steve
2008-10-22 10:31   ` Nick Piggin
2008-10-22 10:31     ` Nick Piggin
2008-10-22 18:46     ` Brad Boyer
2008-10-22 18:46       ` Brad Boyer
2008-10-22 20:19       ` Andi Kleen
2008-10-22 20:19         ` Andi Kleen
2008-10-23  7:08       ` Nick Piggin
2008-10-23  7:08         ` Nick Piggin
2008-10-22 23:07     ` Dave Chinner
2008-10-22 23:07       ` Dave Chinner
2008-10-23  7:07       ` Nick Piggin
2008-10-23  7:07         ` Nick Piggin
2008-10-23  9:44         ` steve
2008-10-23  9:44           ` steve
2008-10-23 11:15           ` Nick Piggin
2008-10-23 11:15             ` Nick Piggin
2008-10-23 22:48             ` Dave Chinner
2008-10-23 22:48               ` Dave Chinner
2008-10-24  1:05               ` Nick Piggin
2008-10-24  1:05                 ` Nick Piggin

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=20081023134804.GL26094@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=akpm@linux-foundation.org \
    --cc=jamie@shareable.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    --cc=npiggin@suse.de \
    --cc=steve@chygwyn.com \
    --cc=zbr@ioremap.net \
    /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.