shmfs development

shmfs development

[Christoph Rohland]

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/