Messages in this thread |  | | | Date | Tue, 02 May 2006 22:19:21 +1000 | | From | Nick Piggin <> | | Subject | Re: [patch 00/14] remap_file_pages protection support |
| |
Ingo Molnar wrote:
> originally i tested this feature with some minimal amount of RAM > simulated by UML 128MB or so. That's just 32 thousand pages, but still > the improvement was massive: context-switch times in UML were cut in > half or more. Process-creation times improved 10-fold. With this feature > included I accidentally (for the first time ever!) confused an UML shell > prompt with a real shell prompt. (before that UML was so slow [even in > "skas mode"] that you'd immediately notice it by the shell's behavior)
Cool, thanks for the numbers.
> > the 'have 1 vma instead of 32,000 vmas' thing is a really, really big > plus. It makes UML comparable to Xen, in rough terms of basic VM design. > > Now imagine a somewhat larger setup - 16 GB RAM UML instance with 4 > million vmas per UML process ... Frankly, without > sys_remap_file_pages_prot() the UML design is still somewhat of a toy.
Yes, I guess I imagined the common case might have been slightly better, however with reasonable RAM utilisation, fragmentation means I wouldn't be surprised if it does easily get close to that worst theoretical case.
My request for numbers was more about the Intel/glibc people than Paolo: I do realise it is a problem for UML. I just like to see nice numbers :)
I think UML's really neat, so I'd love to see this get in. I don't see any fundamental sticking point, given a few iterations, and some more discussion.
-- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
|  |