Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 12 Aug 2002 12:32:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 12 Aug 2002 12:32:27 -0400 Received: from holly.csn.ul.ie ([136.201.105.4]:40204 "HELO holly.csn.ul.ie") by vger.kernel.org with SMTP id ; Mon, 12 Aug 2002 12:32:26 -0400 Date: Mon, 12 Aug 2002 17:36:09 +0100 (IST) From: Mel X-X-Sender: mel@skynet To: Rik van Riel Cc: Daniel Phillips , Bernd Eckenfels , Subject: Re: [ANNOUNCE] VM Regress - A VM regression and test tool In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2733 Lines: 60 On Mon, 12 Aug 2002, Rik van Riel wrote: > The thing is that the indivual 'users' will be downloading > files at modem and adsl speeds, meaning a LOT of apache > daemons could be sitting around on the server. At the moment, VM Regress cannot run multiple instances of the same test (although it should be SMP safe and is written with SMP in mind) but I plan to address that. The problem is not the code running, it's printing out test results but I know how to address it, I just haven't implemented it yet. Because this is a benchmark and not a straight-forward test, another parameter could be added called page reference delay. It would be a time a page would be locked while it was been "transmitted" and then run multiple instances of the test for different transmission speeds. I digress because benchmarks like this are vapourware in VM Regress land at the moment and I'm not prepared to discuss individual benchmarks just yet. > You are right though that this is more of an overall system > benchmark than a pure VM test. On the other hand, the VM > doesn't function on its own, it really needs to be part of > a larger system ;) > I understand that but I believe there is a number of benchmarks that already demonstrate overall performance. A normal benchmark will tell you X bytes was transmitted but won't tell you where time in the kernel was spent and won't tell you anything about the end state of the system. Using VM Regress, you could tell if delays were in page allocation, disk reads, bad swap decisions etc. by running individual micro benchmarks (you can already test __alloc_pages and mmap related routines). A normal benchmark won't tell you and I'm not aware of any tool that can do the equivilant outside of stress testing. That is one of my "selling point". > > Not for that particular benchmark, but how useful would the VM Regress > > equivilant be? > > I can't say in advance how useful it would be, but my gut > feeling is that it might help getting things right. > ok, that is more or less what I was looking for. If I can get some sort of indication from experienced VM developers on whether such a tool is useful, I'll keep developing the tool. I know it doesn't do enough to be truly useful yet. This first release was to find if there was any "What sort of uselessness is that?", "haha, we already have all this information" or "we don't need such data" reactions. -- Mel Gorman MSc Student, University of Limerick http://www.csn.ul.ie/~mel - 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/