Messages in this thread | | | Date | Sat, 5 Jul 2003 01:44:32 +0200 | From | Andrea Arcangeli <> | Subject | Re: What to expect with the 2.6 VM |
| |
I can't disagree more but I don't have any more time to argue with you. Especially your paragraph where you mention pte-highmem wasn't worth an answer. If you for istance could raise one single thing that make me realize I'm missing something, you would have a chance to change my mind. In the meantime it simply seems I fail to communicate with you and the more posts, the less I find those posts informative and useful.
So to avoid endless non informative emails I'm only interested to mention numbers or things where the english language is not involved so there's no risk to disagree anymore.
Since we seem not to have time to hack on a userspace app that you consier to have "pagetable" problems, just tell me a date number (1/1/2005 or 1/1/2010? whatever you want) when you expect a number of significant 64bit programs (1/5/10/200?) to use remap_file_pages with "rather hefty speedups over mmap" (1%/5%/10%/200%?) on 64bit archs and we'll check how many are using it and what kind of improvements they get out of it. this is the only thing I care about. Excluding emulators of course.
My forecast is the number of 64bit apps will be 0, without date limit and the improvement will be of the order of -1/2%.
If it generates as you claim "rather hefty speedups over mmap" on 64bit archs (with rather hefty I hope you mean something more than 1%), you must expect at least a dozen (or at the very least 2/3) of those 64bit apps to be converted to remap_file_pages before 2005 to save the pagetables overhead right? I would also expect to hear from many excited userspace developers to post here agreeing with you, claiming that they're looking forward to drop mmap and to start using remap_file_pages so they can save pagetables, despite they'll generate tlb flushes and pte mangling and they'll enter kernel all the time, and they'll have to reinvent some part of the page replacement of the vm to choose the parameters of remap_file_pages in their 64bit apps. I'm talking about 64bit only of course. We all agree remap_file_pages makes perfect sense in 32bit archs when used on top of shmfs (especially to get rid of rmap in the 2.4 backports).
Also note that by 2005 I guarantee mmap will work in O(log(N)) always (also w/o MAP_FIXED, as worse in 2.7, but infact it might happen even in 2.4) and likely by 2005 the unused pagetables might be garbage collected too, shall anybody think remap_file_pages could help them to drop pagetable overhead.
If you're not confortable to give at least a very conservative forecast for a "rather hefty speedups over mmap" feature like:
1/1/2005 - 2/3 apps - >1% improvement
then you also know you are wrong in my voucabulary but you fail to admit it.
Also please tell me a deadline where you will have mlock dropping rmap merged in mainline and some user tool to raise privilegies via PAM to run mlock as single user, so that 2.5 will be able to run as good as 2.4 for some critical app.
If it's me doing the work you already know what I would do (VM bypass for remap_file_pages, no slowdown and additional complexity in munlock, and a single sysctl to manage security if swap is non null), so I think you prefer me to stay away from remap_file_pages in 2.5. I disagree in the direction you take for 2.5, but since I'll never call into those syscalls in my boxes, I don't mind as far as the rest of the system isn't slowed down or unstable, so I'm fine that you do what you want in that area.
Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |