[lkml]   [1999]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: AIX disclaim() or Tru64 madvise (MADV_DONTNEED) needed
"Dr. Michael Weller" <> writes:

> 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:
> >
> > 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:53    [W:0.067 / U:0.316 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site