> 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.
> 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.
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.
Well, just my 0.02$
Michael.
--Michael Weller: eowmob@exp-math.uni-essen.de, eowmob@ms.exp-math.uni-essen.de, or even mat42b@spi.power.uni-essen.de. If you encounter an eowmob account on any machine in the net, it's very likely it's me.
- 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/