What I noticed was different, and worse: large executables and reading 
large files were both slow.  Loading large executables was especially 
bad.  Python programs for instance ran ok once loaded, but there was a 
delay of several seconds while it loaded the runtime, even when it 
should have been cached.  Executables in Unix, and I think still in 
Linux, are demand paged in: the first block is loaded and executed, and 
as it tries to execute code in other blocks, they are paged in as 
needed.  This makes sense since executables are not normally linearly 
activated.  If each demand page takes inordinate time however this is a 
problem.  There may be a tweak somewhere to readahead more on executables.

I'm happy to say however that after following the suggestion to setup 
TEMPDIR to tmpfs (/dev/shm in modern convention apparently), every flies 
at a very acceptable speed.  I haven't benchmarked yet, but it is 
definitely usable now.

I also switched to a different UML kernel and lowered the memory used 
slightly which has stopped my UML kernel panics after a certain amount 
of processes and disk I/O had elapsed, sometimes only a few minutes.

The context switching problem leads to thinking about VIA architecture 
where the application bypasses the kernel to talk directly to 
virtualized devices.  In this case, that could mean UML processes 
talking more directly to the host kernel.  For network (definitely) and 
disk (maybe), this might make sense.

sdw

Adam Heath wrote:

>yOn Fri, 16 Jan 2004, Stephen D. Williams wrote:
>
>  
>
>>I have noticed that paging an executable (like Python) in takes much
>>more time that it would natively and that large amounts of disk I/O is
>>slow.  Where is the bottleneck for this and what can be done about it?
>>(I realized that the virtual layering is going to cost some.)
>>    
>>
>
>Any context switches(which includes pthreads), or io, in UML, is dog slow.
>
>A context switch underneath uml(and io as well) involes the host uml switching
>from the emulated process, into itself, and back(at the very least).
>
>With the current and forseeable UML implementations, this can't be fixed.
>You'd have to port major portitions of UML to a kernel module(this is more
>than just SKAS).
>
>  
>


-- 
swilliams@hpti.com http://www.hpti.com Personal: sdw@lig.net http://sdw.st
Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw