CVS commit: src

[YAMAMOTO Takashi]

hi,

Module Name: src
Committed By: rmind
Date: Thu Dec 19 19:11:50 UTC 2013
src/lib/libc/gen: sysconf.c
src/lib/librt: Makefile
src/sys/sys: mman.h unistd.h
src/usr.bin/getconf: getconf.c
src/lib/librt: shm.c
Add shm_open(3) and shm_unlink(3) to support POSIX shared memory objects.
They are implemented using tmpfs (mounted at /var/shm).
Discussed on tech-{kern,userlevel} (quite a while ago).

thanks for working on this.

does this (and the relevant sysinst commit) mean that we provide
a different set of functionality depending on the amount of memory?
i don't think it's a good idea. poor performance on poor system
is ok. but the lack of functionality is confusing.
IMO the fstype check should be removed. (and probably make cleartmp
clean /var/shm as well.)

YAMAMOTO Takashi

cvs rdiff -u -r1.35 -r1.36 src/lib/libc/gen/sysconf.c
cvs rdiff -u -r1.16 -r1.17 src/lib/librt/Makefile
cvs rdiff -u -r0 -r1.1 src/lib/librt/shm.c
cvs rdiff -u -r1.44 -r1.45 src/sys/sys/mman.h
cvs rdiff -u -r1.54 -r1.55 src/sys/sys/unistd.h
cvs rdiff -u -r1.34 -r1.35 src/usr.bin/getconf/getconf.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

[Martin Husemann]

Post by YAMAMOTO Takashi
IMO the fstype check should be removed. (and probably make cleartmp
clean /var/shm as well.)

Yes to both!

Martin

[Mindaugas Rasiukevicius]

Hi,

Post by YAMAMOTO Takashi

Add shm_open(3) and shm_unlink(3) to support POSIX shared memory
objects. They are implemented using tmpfs (mounted at /var/shm).
Discussed on tech-{kern,userlevel} (quite a while ago).

thanks for working on this.
does this (and the relevant sysinst commit) mean that we provide
a different set of functionality depending on the amount of memory?
i don't think it's a good idea. poor performance on poor system
is ok. but the lack of functionality is confusing.
IMO the fstype check should be removed. (and probably make cleartmp
clean /var/shm as well.)

If /var/shm is not in tmpfs we return ENOTSUP. My concern is that the
users of this API might have certain expectations about the *speed* of
this memory storage. Think about synchronisation mechanisms implemented
using POSIX shared memory. If the underlying implementation may trigger
disk I/O, the latencies may hit the roof and thus have very significant
impact on the application using such interface. For this reason, I would
even prefer adding wired-only (-w or whatever) mount option for tmpfs and
use it for POSIX shared memory. Yes, mlock(2) is still available, but we
are talking about the defaults and the expectations. If the user does not
have expectations about the speed, then why would it use this API instead
of just mmap()ing a file?

Hence, I leaned towards not supporting the interface, instead of providing
one which does not meet the expectations. What do you think?

Post by YAMAMOTO Takashi
YAMAMOTO Takashi

[Thor Lancelot Simon]

Post by Mindaugas Rasiukevicius
Hence, I leaned towards not supporting the interface, instead of providing
one which does not meet the expectations. What do you think?

This is consistent with what Kirk McKusick and Keith Bostic told me many
years ago about CSRG's thinking on this issue (though of course at the
time the primitives in question were the System V, not the POSIX ones):
that the API is optional and is expected to be memory-backed, and that
users of the API would surely not expect disk-like latencies when it was
called; so if there was no memory filesystem available, the API should
not be provided.

However, this conflicts with the modern "portability" paradigm of doing
all feature tests at compile rather than runtime, so I'm a bit torn;
perhaps better to always mount a tmpfs on /var/shm at install time (or
even explicitly from an independent RC script?) but constrain its size
severely by system memory size at install time?

If we had a way to force tmpfs to page out aggressively when its memory
usage hit a threshold, rather than just having a hard limit on the size
of objects that could be created, that might be good for applications like
this one, no?

[Justin Cormack]

Post by Thor Lancelot Simon

Post by Mindaugas Rasiukevicius
Hence, I leaned towards not supporting the interface, instead of providing
one which does not meet the expectations. What do you think?

This is consistent with what Kirk McKusick and Keith Bostic told me many
years ago about CSRG's thinking on this issue (though of course at the
that the API is optional and is expected to be memory-backed, and that
users of the API would surely not expect disk-like latencies when it was
called; so if there was no memory filesystem available, the API should
not be provided.
However, this conflicts with the modern "portability" paradigm of doing
all feature tests at compile rather than runtime, so I'm a bit torn;
perhaps better to always mount a tmpfs on /var/shm at install time (or
even explicitly from an independent RC script?) but constrain its size
severely by system memory size at install time?

This seems to be what the other OSs do, there is no code to test
whether the filesystem is tmpfs, just assume that if you use the
feature you have it mounted correctly.

You could probably make usage fail by making the mount point have no
read write permissions, so if nothing was mounted there it would fail.
I notice Ubuntu Linux makes /dev/shm (which is what shmopen looks for)
a symlink to /run/shm where /run is a tmpfs filesystem too, so if you
haven't mounted the standard tmpfs filesystems all access will fail
completely.

Justin

[Christos Zoulas]

Post by Justin Cormack

Post by Thor Lancelot Simon

Post by Mindaugas Rasiukevicius
Hence, I leaned towards not supporting the interface, instead of providing
one which does not meet the expectations. What do you think?

This is consistent with what Kirk McKusick and Keith Bostic told me many
years ago about CSRG's thinking on this issue (though of course at the
that the API is optional and is expected to be memory-backed, and that
users of the API would surely not expect disk-like latencies when it was
called; so if there was no memory filesystem available, the API should
not be provided.
However, this conflicts with the modern "portability" paradigm of doing
all feature tests at compile rather than runtime, so I'm a bit torn;
perhaps better to always mount a tmpfs on /var/shm at install time (or
even explicitly from an independent RC script?) but constrain its size
severely by system memory size at install time?

This seems to be what the other OSs do, there is no code to test
whether the filesystem is tmpfs, just assume that if you use the
feature you have it mounted correctly.
You could probably make usage fail by making the mount point have no
read write permissions, so if nothing was mounted there it would fail.
I notice Ubuntu Linux makes /dev/shm (which is what shmopen looks for)
a symlink to /run/shm where /run is a tmpfs filesystem too, so if you
haven't mounted the standard tmpfs filesystems all access will fail
completely.
Justin

You could make shm_open to statvfs and print a warning or exit with an
error the first time it is used if it is not on tmpfs.

christos

[Thor Lancelot Simon]

Post by Justin Cormack
I notice Ubuntu Linux makes /dev/shm (which is what shmopen looks for)
a symlink to /run/shm where /run is a tmpfs filesystem too, so if you
haven't mounted the standard tmpfs filesystems all access will fail
completely.

This actually seems like a very nice idea.

Thor

[Mindaugas Rasiukevicius]

Post by Thor Lancelot Simon

Post by Mindaugas Rasiukevicius
Hence, I leaned towards not supporting the interface, instead of
providing one which does not meet the expectations. What do you think?

This is consistent with what Kirk McKusick and Keith Bostic told me many
years ago about CSRG's thinking on this issue (though of course at the
that the API is optional and is expected to be memory-backed, and that
users of the API would surely not expect disk-like latencies when it was
called; so if there was no memory filesystem available, the API should
not be provided.

Interesting to hear some earlier thoughts on this!

There is one aspect which is worthwhile to point out. POSIX shared memory
is a POSIX "real time extension" (not that it matters how is it labelled).
However, UNIX was never designed with hard real-time systems in mind i.e.
most facilities work on best-effort basis.

So my position is not very strong on this. On the other hand, I would
like to see NetBSD as a solid framework which could be used as a base for
building, at least, soft real-time systems. There is still a lot of work
to do, but it is about the time to have discussions like this.

Post by Thor Lancelot Simon
However, this conflicts with the modern "portability" paradigm of doing
all feature tests at compile rather than runtime, so I'm a bit torn;
perhaps better to always mount a tmpfs on /var/shm at install time (or
even explicitly from an independent RC script?) but constrain its size
severely by system memory size at install time?

It is my thinking as well. I agree that ENOTSUP sucks, but it serves as
a *guard* for missing tmpfs mount. Otherwise, tmpfs is available on all
ports and I see no reason why it could not be always provided (well, maybe
not on acorn26, but who cares).

[YAMAMOTO Takashi]

Post by Mindaugas Rasiukevicius

Post by Thor Lancelot Simon

Post by Mindaugas Rasiukevicius
Hence, I leaned towards not supporting the interface, instead of
providing one which does not meet the expectations. What do you think?

This is consistent with what Kirk McKusick and Keith Bostic told me many
years ago about CSRG's thinking on this issue (though of course at the
that the API is optional and is expected to be memory-backed, and that
users of the API would surely not expect disk-like latencies when it was
called; so if there was no memory filesystem available, the API should
not be provided.

Interesting to hear some earlier thoughts on this!
There is one aspect which is worthwhile to point out. POSIX shared memory
is a POSIX "real time extension" (not that it matters how is it labelled).
However, UNIX was never designed with hard real-time systems in mind i.e.
most facilities work on best-effort basis.
So my position is not very strong on this. On the other hand, I would
like to see NetBSD as a solid framework which could be used as a base for
building, at least, soft real-time systems. There is still a lot of work
to do, but it is about the time to have discussions like this.

Post by Thor Lancelot Simon
However, this conflicts with the modern "portability" paradigm of doing
all feature tests at compile rather than runtime, so I'm a bit torn;
perhaps better to always mount a tmpfs on /var/shm at install time (or
even explicitly from an independent RC script?) but constrain its size
severely by system memory size at install time?

It is my thinking as well. I agree that ENOTSUP sucks, but it serves as
a *guard* for missing tmpfs mount. Otherwise, tmpfs is available on all
ports and I see no reason why it could not be always provided (well, maybe
not on acorn26, but who cares).

then please provide it regardless of the amount of memory a system
happens to have when installing OS.

and IMO requiring to build a custom librt is too strong guard for
things like this.

YAMAMOTO Takashi

Post by Mindaugas Rasiukevicius
--
Mindaugas

[Martin Husemann]

Post by YAMAMOTO Takashi
then please provide it regardless of the amount of memory a system
happens to have when installing OS.

Easy to do, but the "realtime" argument is purely academic for the affected
systems - I'd prefer to remove the fs_type check as well. A sun2 with 8 MB
RAM will not provide anything similar to what software authors expect
for shm_open() according to Mindaugas.

Anyway, current state is inconsistent: only new installs check the memory,
system updates via postinstall do always create the tmpfs. This needs
fixing, but we should agree on which way first.

Martin

[YAMAMOTO Takashi]

Post by Mindaugas Rasiukevicius
Hi,

Post by YAMAMOTO Takashi

Add shm_open(3) and shm_unlink(3) to support POSIX shared memory
objects. They are implemented using tmpfs (mounted at /var/shm).
Discussed on tech-{kern,userlevel} (quite a while ago).

thanks for working on this.
does this (and the relevant sysinst commit) mean that we provide
a different set of functionality depending on the amount of memory?
i don't think it's a good idea. poor performance on poor system
is ok. but the lack of functionality is confusing.
IMO the fstype check should be removed. (and probably make cleartmp
clean /var/shm as well.)

If /var/shm is not in tmpfs we return ENOTSUP. My concern is that the
users of this API might have certain expectations about the *speed* of
this memory storage. Think about synchronisation mechanisms implemented
using POSIX shared memory. If the underlying implementation may trigger
disk I/O, the latencies may hit the roof and thus have very significant
impact on the application using such interface. For this reason, I would
even prefer adding wired-only (-w or whatever) mount option for tmpfs and
use it for POSIX shared memory. Yes, mlock(2) is still available, but we
are talking about the defaults and the expectations. If the user does not
have expectations about the speed, then why would it use this API instead
of just mmap()ing a file?

because the api is easier to use?

Post by Mindaugas Rasiukevicius
Hence, I leaned towards not supporting the interface, instead of providing
one which does not meet the expectations. What do you think?

does returning ENOTSUP improve the situation?
it merely make the most applications abort or crash, i guess.

YAMAMOTO Takashi

Post by Mindaugas Rasiukevicius

Post by YAMAMOTO Takashi
YAMAMOTO Takashi

--
Mindaugas

[Mindaugas Rasiukevicius]

Post by YAMAMOTO Takashi
because the api is easier to use?

They have the same semantics, so not really.

Post by YAMAMOTO Takashi

Post by Mindaugas Rasiukevicius
Hence, I leaned towards not supporting the interface, instead of
providing one which does not meet the expectations. What do you think?

does returning ENOTSUP improve the situation?
it merely make the most applications abort or crash, i guess.

It serves as a guard.