Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: [RFC] [RFT] Shared /dev/zero mmaping feature | From | Christoph Rohland <> | Date | 01 Mar 2000 18:55:12 +0100 |
| |
kanoj@google.engr.sgi.com (Kanoj Sarcar) writes:
> 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 ...
We can tune all these parameters at runtime. This should not be a reason.
> 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.
IMHO all this SYSV ipc stuff is a totally broken API and many agree with me. I do not care to clutter up the output of it a little bit for this feature.
Nobody can know who is creating private IPC segments. So nobody should be irritated by some more segments displayed/used.
In the contrary: I like the ability to restrict the usage of these segments with the ipc parameters. Keep in mind you can stack a lot of segments for a DOS attack. and all the segments will use the whole memory.
> 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 ...
It makes shm fs a lot more work. And the special handling slows down shm handling.
Greetings Christoph
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |