Messages in this thread | | | Date | Tue, 9 Mar 2004 20:57:52 +0100 | From | Ingo Molnar <> | Subject | Re: objrmap-core-1 (rmap removal for file mappings to avoid 4:4 in <=16G machines) |
| |
* Andrea Arcangeli <andrea@suse.de> wrote:
> > (OASB is not a full-disclosure benchmark so i have no way to check > > this.) All you have proven is that workloads with a limited number of > > per-inode vmas can perform well. Which completely ignores my point. > > what is your point, that OASB is a worthless workload and the only > thing that matters is TPC-C? [...]
not at all. I pointed out specific workloads that create tons of vmas, which would perform very bad if swapping. OASB is not one of those workloads. [I could also mention UML which currently creates a vma per virtualized page, which, with a low-end UML setup, generates tens of thousands of vmas as well.]
(if the linear search is fixed then i have no objections, but for the current code to hit any mainline kernel we would first need to redefine 'enterprise quality'. My main worry is that we are now at a dozen emails regarding this topic and you still dont seem to be aware of the severity of this quality of implementation problem.)
sure, remap_file_pages() fixes such problems - while i'm happy if more people use remap_file_pages(), apps are not (and should not be) forced to use remap_file_pages() and i refuse to concede that the VM must inevitably get wedged with just a couple of thousand vmas created on a 256 MB 500 MHz box ... I dont know how to put this point in a simpler way. This stuff must not be added (to mainline) until it can take the load.
Ingo - 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/
| |