From: Christoph Rohland <cr@sap.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org, ch.rohland@gmx.net
Subject: Re: [PATCH,preliminary] cleanup shm handling
Date: 08 Dec 2000 23:21:57 +0100 [thread overview]
Message-ID: <m3snnyo92i.fsf@linux.local> (raw)
In-Reply-To: <Pine.LNX.4.10.10012081023170.11302-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.10.10012081023170.11302-100000@penguin.transmeta.com>
Hi Linus,
Linus Torvalds <torvalds@transmeta.com> writes:
> On 8 Dec 2000, Christoph Rohland wrote:
> >
> > here is my first shot for cleaning up the shm handling. It did
> > survive some basic testing but is not ready for inclusion.
>
> The only comment I have right now is that you probably should not
> mark the page dirty in "nopage" - theoretically somebody might have
> a sparse mapping and depend on zero pages for the ones that aren't
> touched. It's better to delay the dirty marking until swapout() (and
> write(), when that is implemented), so that we don't needlessly
> create swap entries for zero pages.
OK. I simply copied that from shm.c without thinking. Actually I do
not yet understand the implications of it. (I never thought that I
would get so deeply involved into these issues and still struggle
often with the details)
> Other than that the approach at least looks reasonable. And cleaner
> than what we currently have.
Only reasonable? :-(
It's what I always thought would be the Right Thing (TM):
1) The mm layer should have the abilty to handle shared anonymous
pages
2) To access this we should use the 'everything is a file' mantra
which means shm fs
3) sysv shm should only care about handling shm ids (and it special
attributes which unfortunately makes shm_vm_operations necessary.)
So how would you improve it conceptually? And where are the
implementation flaws?
And compared to all the ipc/shm.c hacks we had so far it looks for me
beautiful. (And to make this clear: The main part is not my work. I
simply gathered the work of others to make this possible)
Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-12-08 22:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-08 13:23 [PATCH,preliminary] cleanup shm handling Christoph Rohland
2000-12-08 15:13 ` David Howells
2000-12-08 20:04 ` Christoph Rohland
2000-12-13 11:51 ` David Howells
2000-12-13 13:52 ` Christoph Rohland
2000-12-13 16:43 ` David Howells
2000-12-13 17:15 ` Christoph Rohland
2000-12-13 17:29 ` David Howells
2000-12-08 18:26 ` Linus Torvalds
2000-12-08 22:21 ` Christoph Rohland [this message]
2000-12-08 22:36 ` Linus Torvalds
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=m3snnyo92i.fsf@linux.local \
--to=cr@sap.com \
--cc=ch.rohland@gmx.net \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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.