> Thanks, rlhamil. > > If I am not wrong and if the memory I want madvise > on is indeed allocated by calling "malloc()", libc > should use mmap() and sbrk() to create and expand the > heap area, right?
Without checking, I suspect the "normal" version of malloc() uses sbrk() to expand the heap. There is also -lmapmalloc that explicitly uses mmap() of anonymous memory instead of sbrk(). > If this is the case, madvise should work on this > piece of memory, right? But as far as my kernel > digging, it seems this advice does not reaches to the > paging out level, ie. page out decisions are not > affected by our _advices_ set by madvise. If this > understanding is correct, I would not count on this > mechanism to do my work. > > Basically, I want to do some early evictions of pages > that will not be used in near future, but keeping as > many useful pages as possible in physical memory. I > have an algorithm to calculate the usefulness and > predict their usage in this particular context. > > I've done similar things in Linux by modifying kernel > since I was unaware of madvise() back then. This time > I think madvise, if indeed work, should save much > work given my newbie status. > > Any good ideas? I guess the real question is whether madvise() does (or should do) anything on stack, heap, and anonymous (or private - changes go to swap rather than the file) mappings. Unless someone knows off the top of their head what the intended behavior for those should be, that means a lot of reading code, or testing, or both. Another thing I just saw was memcntl(2) MC_SYNC with MS_INVALIDATE, but I don't know if that will work any better. -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
