From: <ch...@in...> - 2003-12-02 04:15:37
|
Has anyone found a solution to this problem yet? I have just recently came across what seems to be the exact same problem. In my configuration I have a dual Celeron 466 machine that is out performing an Athlon 1800. I came about this problem when going from a UML kernel built from 2.4.20 vanilla + uml-patch-2.4.20-4 to linux-2.4.21-135-um from SuSE. Both systems are running on SuSE stock kernel 2.4.21-99 but the Celeron is on the SMP-4G kernel and the Athlon on the 2.4.21-99-athlon kernel. When I had the Athlon host on a vanilla kernel 2.4.21 + skas (compiled for athlon) and vanilla UML kernel all was good. The dual Celeron however, exhibits no problems what so ever on any kernel. I found nearly the same results as Ryan when running vmstat on the hosts and UML. All configurations are using skas mode and tuntap networking. Both machines have 5400 rpm IDE drives and 512mb RAM. If I boot the Athlon host with the vanilla 2.4.21 kernel everything performs great. No version of the SuSE 2.4.21-99 kernel performs on the Athlon. It spends almost all of its time on disk IO even when everything is idol. I haven't isolated where all the extra IO is coming from yet either. Nor have I been able to figure out why on the Celeron everything works great but not on the Athlon with the same kernels. Any suggestions on how to further isolate this problem? Thanks, Chip Schweiss > > On Fri, 24 Oct 2003, Jeff Dike wrote: > > > li...@rk... said: > > > I have seen some posts to this list that expanding the on > disk usage > > > of a sparse file can be time consuming. But the strange > part of this > > > problem is that on one machine, these lockups are less > than a second > > > (a few hundred milliseconds), and on the other machine they are > > > several seconds (10-40 seconds). The former machine is a P2-400 w/ > > > 256MB RAM, and 30GB IDE HD. The latter machine is a > Athlon 1.4GHz w/ > > > 1GB RAM, and 3x36GB Ultra160 RAID5 (software) SCSI array. > So, yes, the > > > far faster machine is showing these lockups much worse > than the slower > > > machine. :( > > > > Is it just the UML that's wedged, or the whole box? > > Just the UML that is wedged, the host is just fine, as > if nothing > out of the ordinary was going on. > > > If it's really many 10s of seconds, then some vmstat data would be > > interesting. Start it during this period and let it run > for a little > > afterwards so that the difference is apparent. > > Okay, attached are four files from my two different machines: > > vmstat-slow.host.log :: Host 'vmstat 1' log on the P2. > vmstat-slow.uml.log :: UML 'vmstat 1' log on the P2. > > vmstat-fast.host.log :: Host 'vmstat 1' log on the Athlon. > vmstat-fast.uml.log :: UML 'vmstat 1' log on the Athlon. > > For each pair of files, vmstat was started on both the host and UML at > about the same time and allowed to run for ~30 seconds. Then > a copy via > netcat and afio of ~200MB of PDF files over a 100mbit network from a > separate machine (not the UML host) to the UML was started. I am using > bridging and tuntap for network access. The filesystem image > being used is > a sparse file, and it expanded by at least 100MB during the > file copy. The > only difference I can see between the two UML instances is > that on the P2 > the allocated memory for the UML is 64MB, while on the Athlon > it is 128MB. > The vmstat-fast.uml.log is quite interesting, as it is > much, much > shorter than the vmstat-fast.host.log. The reason it is > shorter is due to > the UML system being wedged for much of the copy. The P2 took only a > minute to do this transfer, while the Athlon took nearly five > minutes. > Hopefully these logs are of use. If there are any other tests I > can run, please let know. Thanks! > > -------------------------------------------------------------- > ------------- > | "For to me to live is Christ, and to die is gain." > | > | --- Philippians > 1:21 (KJV) | > -------------------------------------------------------------- > ------------- > | Ryan Kirkpatrick | Boulder, Colorado | > http://www.rkirkpat.net/ | > -------------------------------------------------------------- > ------------- > |