On Tue, Jan 09, 2001 at 02:59:07PM -0800, Linus Torvalds wrote:
>
> Arguably the new semantics are perfectly valid semantics on their own, but
> I'm not sure they are acceptable.
>
> In contrast, the PG_realdirty approach would give the old behaviour of
> truly locked-down shm segments, with not significantly different
> complexity behaviour.
>
> What do other UNIXes do for shm_lock()?
>
It appears that the fine-detail semantics vary across the board. DYNIX/ptx
supports two forms of SysV shm locking - soft and hard. Soft-locking (the
default) merely makes the pages sticky, so if you fault them in, they stay
in your resident set, but don't count against it. If, however the process
swaps, they're all evicted, and when the process is swapped back in, you
get to fault the back in all over again. Hard locking pins the segment into
physical memory until such time as it's destroyed. It stays there even if
there are currently no attaches. Again, such pages are not counted against
the process RSS.
SVR4 only support one form. It faults all the pages in and locks them into
memory, but doesn't treat the especially wrt rss/paging, which seems none
too clever - if they're locked into memory, you might as well use them :-)
[Details of the differing approches omitted]
>
> Does anybody have any better pointers, ideas, or opinions?
>
> Linus
>
I don't know if there are any arguments in favour of making both approaches
available. Gut feel says that's overkill. We ended up with two by historical
accident. The soft-locking was always there (althought semantically different
to SVR4), and the hard-locking stuff was added to boost performance with a
certain six-letter RDBMS that attaches an SGA to each process. They all get
to attach it "for free", and since it doesn't count towards the RSS, it
allowed tuning a fairly small RSS across the system without having the RDMBS
processes spent all their time (soft) faulting SGA pages in and out of their
RSS.
Tim
-- Tim Wright - timw@splhi.com or timw@aracnet.com or twright@us.ibm.com IBM Linux Technology Center, Beaverton, Oregon "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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/