[lkml]   [2006]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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

SUSE Labs, Novell Inc.
Send instant messages to your online friends

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-05-03 00:12    [W:0.077 / U:39.124 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site