[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.026 / U:0.836 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site