From: kanoj@google.engr.sgi.com (Kanoj Sarcar)
To: Christoph Rohland <hans-christoph.rohland@sap.com>
Cc: Linus Torvalds <torvalds@transmeta.com>,
linux-mm@kvack.org, linux-kernel@vger.rutgers.edu
Subject: Re: [RFC] [RFT] Shared /dev/zero mmaping feature
Date: Wed, 1 Mar 2000 09:34:53 -0800 (PST) [thread overview]
Message-ID: <200003011734.JAA74642@google.engr.sgi.com> (raw)
In-Reply-To: <qwwputenba1.fsf@sap.com> from "Christoph Rohland" at Mar 01, 2000 01:08:06 PM
>
> Hi Kanoj and Linus,
>
> kanoj@google.engr.sgi.com (Kanoj Sarcar) writes:
>
> > [snip]
> >
> > I do not believe there is any good reason to expose the special
> > shared memory segment used as a place holder for all /dev/zero
> > mappings to users via ipc* commands. This special segment exists
> > only because we want to reduce kernel code duplication, and all the
> > zshmid_kernel/ zero_id checks just make sure that regular shared
> > memory works pretty much the way it did before. (One thing I am
> > unhappy about is that this special segment eats up a shm id, but
> > that's probably not too bad).
>
> The appended proposal reduces code duplication and complexity a
> lot. (The diff47 needs your patches against other files added.)
>
What you have sent is what I used as a first draft for the implementation.
The good part of it is that it reduces code duplication. The _really_ bad
part is that it penalizes users in terms of numbers of shared memory
segments, max size of /dev/zero mappings, and limitations imposed by
shm_ctlmax/shm_ctlall/shm_ctlmni etc. I do not think taking up a
shmid for each /dev/zero mapping is a good idea ...
Furthermore, I did not want to change behavior of information returned
by ipc* and various procfs commands, as well as swapout behavior, thus
the creation of the zmap_list. I decided a few lines of special case
checking in a handful of places was a much better option.
If the current /dev/zero stuff hampers any plans you have with shm code
(eg page cachification), I would be willing to talk about it ...
Kanoj
> I would vote to apply diff48 to the standard kernel. For me the whole
> solution is still a workaround.
>
> Greetings
> Christoph
--
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/
next prev parent reply other threads:[~2000-03-01 17:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-25 23:08 [RFC] [RFT] Shared /dev/zero mmaping feature Kanoj Sarcar
2000-02-26 16:38 ` Linus Torvalds
2000-02-26 21:47 ` Kanoj Sarcar
2000-02-29 10:54 ` Christoph Rohland
2000-02-29 18:30 ` Kanoj Sarcar
2000-03-01 12:08 ` Christoph Rohland
2000-03-01 17:34 ` Kanoj Sarcar [this message]
2000-03-01 17:55 ` Christoph Rohland
2000-03-01 18:18 ` Kanoj Sarcar
2000-03-01 19:42 ` Christoph Rohland
2000-03-01 20:09 ` Kanoj Sarcar
2000-03-06 22:43 ` Stephen C. Tweedie
2000-03-06 23:01 ` Kanoj Sarcar
2000-03-08 12:02 ` Christoph Rohland
2000-03-08 17:51 ` Kanoj Sarcar
2000-03-08 18:35 ` Christoph Rohland
2000-03-08 18:48 ` Linus Torvalds
2000-03-08 18:57 ` Kanoj Sarcar
2000-03-09 18:15 ` Christoph Rohland
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=200003011734.JAA74642@google.engr.sgi.com \
--to=kanoj@google.engr.sgi.com \
--cc=hans-christoph.rohland@sap.com \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.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.