Re: objrmap and vmtruncate

[Benjamin LaHaise]

On Sat, Apr 05, 2003 at 03:31:43AM +0200, Andrea Arcangeli wrote:
> Also consider this significant factor: the larger the shmfs the smaller
> the nonlinear 1G window will be and the higher the trashing. With 32G of
> bigpages the remap_file_pages will trash like crazy generating an order
> of mangnitude more of "window misses". I mean 32bit are just pushed at
> the limit today regardless the lack of remap_file_pages. Example, if
> you don't use largepages going past 16G of shm is going to be derimental.
> The cost of the mmap doesn't sounds like the showstopper.

You're guessing here.  At least for oracle, that behaviour is dependant on 
the locality of accesses.  Given that each user has their own process you 
can bet there is a fair amount of locality to their transactions.

> you could try to avoid the need of the sysctl by teaching the vm to
> unmap such vma, but I don't think it worth and I'm sure those apps
> prefers to have the stuff pinned anyways w/o the risk of sigbus and w/o
> the need of mlock and it looks cleaner to me to avoid any mess with the
> vm and long term nobody will care about this sysctl since 64bit will run
> so much fatster w/o any remap_file_pages and tlb flush running at all

It is still useful for things outside of the pure databases on 32 bits 
realm.  Consider a fast bochs running 32 bit apps on a 64 bit machine -- 
should it have to deal with the overhead of zillions of vmas for emulating 
page tables?

If anything, I think we should be moving in the direction of doing more 
along the lines of remap_file_pages: things like executables might as well 
keep their state in page tables since we never discard them and instead 
toss the vma out the window.

		-ben
-- 
Junk email?  <a href="mailto:[e-mail]">[e-mail]</a>