lkml.org 
[lkml]   [2000]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] [RFT] Shared /dev/zero mmaping feature
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.049 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site