> On 20 Aug 1999, Christoph Rohland wrote:
>
> > Hi all,
> >
> > For really good operation of SAP R/3 we would need a call like AIX's
> > disclaim or Tru64's madvise(MADV_DONTNEED): From 'man madvise' of
> > Tru64:
> >
> > 'MADV_DONTNEED
> > Do not need these pages
> >
> > The system will free any whole pages in the specified
> > region. All modifications will be lost and any swapped
> > out pages will be discarded. Subsequent access to the
> > region will result in a zero-fill-on-demand fault as
> > though it is being accessed for the first time...'
>
> Hmm, although I like madvise (but was told that the kernel is better to
> fine tune read ahead charakteristics based on disk speed etc), I must
> admit that this interpretation is a really odd misuse of the madvise
> function which is intented for speed optimizations only, not to remove
> mappings or have any semantic effect at all.
Yes I think you are right and the True64 people misinterpreted the
call. This is the reason why I proposed another flag.
> > I looked into the shm code and to implement this special case would be
> > very easy, but I believe it should probably be implemented for all
> > anonymous or shared pages.
>
> I think in any normal situations you could just unmap the region and map
> it again. Or actually just mmap a new region over the old.
>
> But I see you've a special need here: I assume your real problem is that
> there are two processes sharing a memory region and one of them wants to
> dealloc any buffers used by the region for optimization. And just
> unmapping and mapping does not help because all processes would have to do
> that.
Yes that's right. We need this for shared pages, i.e. SYSV shm.
> You could have the sending process shared mmap a new area and pass on to
> the recipient(s) it's location and then, through some usgae counters, all
> procs unmap it again. But I see your concern about too many OS calls and
> interproc communication.
>
> I think you always have a filedescriptor for such shm games, so an ioctl
> on the file does add no real new syscall (which also has C-library
> implications) and is odd enough to scare people using it except when they
> really, really need it.
You can not use file descriptors for shared memory since they sync to
file on unmap. This would be possible if we had shm_open which
implements shared memory with the normal fd/mmap/unmap syntax.
Also we are not able to change the general implementation of the R/3
kernel, but have to choose between several given options.
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/