All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Jamie Lokier <jamie.lokier@cern.ch>
Cc: "Eric W. Biederman" <ebiederm+eric@ccr.net>,
	Chuck Lever <cel@monkey.org>,
	linux-mm@kvack.org
Subject: Re: Extensions to mincore
Date: Tue, 21 Mar 2000 16:08:28 +0000	[thread overview]
Message-ID: <20000321160828.C8204@redhat.com> (raw)
In-Reply-To: <20000321165532.A5461@pcep-jamie.cern.ch>; from jamie.lokier@cern.ch on Tue, Mar 21, 2000 at 04:55:32PM +0100

Hi,

On Tue, Mar 21, 2000 at 04:55:32PM +0100, Jamie Lokier wrote:
> 
> Didn't you read a few paragraphs down, where I explain how to implement
> this?  You've got struct page.  It is enough for private mappings, and
> we don't need this feature for shared mappings.

Umm, yes, but just saying "we'll solve synchronisation problems by 
stopping all the other threads" hardly seems like a "solution" to me:
more of a workaround of the problem!  mprotect() does work correctly
without stopping other threads.

> It would be enough the say "the mincore accessed/dirty bits are not
> guaranteed to be accurate if pages are accessed by concurrent threads
> during the mincore call".

Exactly why you need mprotect, which _does_ make the necessary 
guarantees.

Oh, and suggesting that we can obtain the dirty bit by assuming all
mappings are private doesn't work either.  Private mappings *need* a 
per-pte (NOT per-page, but per-pte) dirty bit to distinguish between 
pages shared with the underlying mapped object, and pages which have
been modified by the local process.

--Stephen

--
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.eu.org/Linux-MM/

  reply	other threads:[~2000-03-21 16:08 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20000320135939.A3390@pcep-jamie.cern.ch>
2000-03-20 19:09 ` MADV_SPACEAVAIL and MADV_FREE in pre2-3 Chuck Lever
2000-03-21  1:20   ` madvise (MADV_FREE) Jamie Lokier
2000-03-21  2:24     ` William J. Earl
2000-03-21 14:08       ` Jamie Lokier
2000-03-22 16:24     ` Chuck Lever
2000-03-22 18:05       ` Jamie Lokier
2000-03-22 21:39         ` Chuck Lever
2000-03-22 22:31           ` Jamie Lokier
2000-03-22 22:44             ` Stephen C. Tweedie
2000-03-23 18:53             ` Chuck Lever
2000-03-24  0:00               ` /dev/recycle Jamie Lokier
2000-03-24  9:14                 ` /dev/recycle Christoph Rohland
2000-03-24 13:10                   ` /dev/recycle Jamie Lokier
2000-03-24 13:54                     ` /dev/recycle Christoph Rohland
2000-03-24 14:17                       ` /dev/recycle Jamie Lokier
2000-03-24 17:40                         ` /dev/recycle Christoph Rohland
2000-03-24 18:13                           ` /dev/recycle Jamie Lokier
2000-03-25  8:35                             ` /dev/recycle Christoph Rohland
2000-03-28  0:48                 ` /dev/recycle Chuck Lever
2000-03-24  0:21               ` madvise (MADV_FREE) Jamie Lokier
2000-03-24  7:21                 ` lars brinkhoff
2000-03-24 17:42                   ` Jeff Dike
2000-03-24 16:49                     ` Jamie Lokier
2000-03-24 17:08                     ` Stephen C. Tweedie
2000-03-24 19:58                       ` Jeff Dike
2000-03-25  0:30                         ` Stephen C. Tweedie
2000-03-22 22:33           ` Stephen C. Tweedie
2000-03-22 22:45             ` Jamie Lokier
2000-03-22 22:48               ` Stephen C. Tweedie
2000-03-22 22:55                 ` Q. about swap-cache orphans Jamie Lokier
2000-03-22 22:58                   ` Stephen C. Tweedie
2000-03-22 18:15       ` madvise (MADV_FREE) Christoph Rohland
2000-03-22 18:30         ` Jamie Lokier
2000-03-23 16:56           ` Christoph Rohland
2000-03-21  1:29   ` MADV_DONTNEED Jamie Lokier
2000-03-22 17:04     ` MADV_DONTNEED Chuck Lever
2000-03-22 17:10       ` MADV_DONTNEED Stephen C. Tweedie
2000-03-22 17:32         ` MADV_DONTNEED Jamie Lokier
2000-03-22 17:33         ` MADV_DONTNEED Jamie Lokier
2000-03-22 17:37           ` MADV_DONTNEED Stephen C. Tweedie
2000-03-22 17:43       ` MADV_DONTNEED Jamie Lokier
2000-03-22 21:54         ` MADV_DONTNEED Chuck Lever
2000-03-22 22:41           ` MADV_DONTNEED Jamie Lokier
2000-03-23 19:13             ` MADV_DONTNEED James Antill
2000-03-21  1:47   ` Extensions to mincore Jamie Lokier
2000-03-21  9:11     ` Eric W. Biederman
2000-03-21  9:40       ` lars brinkhoff
2000-03-21 11:34       ` Stephen C. Tweedie
2000-03-21 15:15         ` Jamie Lokier
2000-03-21 15:41           ` Stephen C. Tweedie
2000-03-21 15:55             ` Jamie Lokier
2000-03-21 16:08               ` Stephen C. Tweedie [this message]
2000-03-21 16:48                 ` Jamie Lokier
2000-03-22  7:36                   ` Eric W. Biederman
2000-03-21  1:50   ` MADV flags as mmap options Jamie Lokier

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=20000321160828.C8204@redhat.com \
    --to=sct@redhat.com \
    --cc=cel@monkey.org \
    --cc=ebiederm+eric@ccr.net \
    --cc=jamie.lokier@cern.ch \
    --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.