From: Christoph Rohland <hans-christoph.rohland@sap-ag.de>
To: ebiederm+eric@npwt.net, linux-mm@kvack.org
Cc: niels.mache@delix.de
Subject: shmfs development
Date: 24 Aug 1999 11:20:46 +0200 [thread overview]
Message-ID: <qww7lmlbklt.fsf@sap.com> (raw)
Hi all,
We are doing very well here with SAP R/3 on Linux and I am very
confident that it will be a success, but...
we have to do Linux on 32 bit machines. On the other side SAP
R/3 is designed to handle many clients at a time in a small number of
processes.
Our normal memory management simply maps all user context memory at
once into all processes. This leads to a shortage of address space and
thus useable memory.
We have two special implementations which break the 32bit limit by
mapping only the currently used context into the address space:
One implementation works with large SYSV shm segments. Each segment is
used exclusively for one context. To not die due to swapping we need a
disclaim or madvise system call for this implementation. This would
enable us to tell the system which memory content is invalid. So the
sytem can free the memory instead of paging it out. Since the disclaim
call seems for many people an unnecessary bloat of the kernel
interface I do not see a big chance to get this into the linux kernel.
The other implementation uses posix shared memory and maps different
blocks of a posix shm segment into one contiguous area. This one would
be our preferred implementation. In this case we can reuse freed
blocks of one context in another context. So we do not need the
disclaim system call for this implementation.
My question is now: Is there a chance to get shmfs in the near future?
If not I would propose to implement a minimal fs which implements
fileaccess to SYSV shm segments. The SYSV shm has nearly all internal
calls needed for posix shm: We can map and unmap arbitrary areas. The
only feature needed internally is a resize call.
Any comments?
Christoph
--
______________________________________________
Christoph Rohland, LinuxLab, SAP-AG, Germany
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
reply other threads:[~1999-08-24 9:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=qww7lmlbklt.fsf@sap.com \
--to=hans-christoph.rohland@sap-ag.de \
--cc=ebiederm+eric@npwt.net \
--cc=linux-mm@kvack.org \
--cc=niels.mache@delix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox