Messages in this thread | | | Subject | Re: AIX disclaim() or Tru64 madvise (MADV_DONTNEED) needed | From | Christoph Rohland <> | Date | 20 Aug 1999 15:46:15 +0200 |
| |
"Dr. Michael Weller" <eowmob@exp-math.uni-essen.de> 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: > > > > '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/
| |