[uml-devel] What is the most up to date, least crashing kernel+patch?

[uml-devel] What is the most up to date, least crashing kernel+patch?

[Stephen D. Williams]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

I would like 2.6.1 as a UML kernel along with support for >512 UML ram 
and preferrably modules.  What is the best I can get right now?

I'm running Gerd/SuSE's 2.6.0-test9, but I'm having severe problems with 
periodic crashes.  These appear to be preceded by a 'do_io' error on 
/dev/hdb, but I've bumped all ulimits to large levels, including max 
files (100000).  (There seems to be conflicting notes about whether I 
need a modified glibc or headers updated and the host kernel 
recompiled.)  The system runs well for a while and then just disappears.

I've had trouble compiling with some of the recent 2.6.0/2.6.1 patches 
and I need clarification.

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.)

Thanks
sdw

-- 
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



[-- Attachment #2: sdw.vcf --]
[-- Type: text/x-vcard, Size: 234 bytes --]

begin:vcard
fn:Stephen Williams
n:Williams;Stephen
email;internet:sdw@lig.net
tel;work:703-724-0118
tel;fax:703-995-0407
tel;pager:sdwpage@lig.net
tel;home:703-729-5405
tel;cell:703-371-9362
x-mozilla-html:TRUE
version:2.1
end:vcard

[uml-devel] Re: What is the most up to date, least crashing kernel+patch?

[Gerd Knorr]

"Stephen D. Williams" <sdw@lig.net> writes:

> I would like 2.6.1 as a UML kernel along with support for >512 UML ram
> and preferrably modules.  What is the best I can get right now?
> 
> I'm running Gerd/SuSE's 2.6.0-test9,

ftp://ftp.suse.com/pub/people/kraxel/i386/ has 2.6.1 rpms since a few
hours.  Both binary and source rpms, both uml and host, host with
skas3, all building out a single source tree.  Modules don't work yet
through.

  Gerd

-- 
"... und auch das ganze Wochenende oll" -- Wetterbericht auf RadioEins


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: What is the most up to date, least crashing kernel+patch?

[Stephen D. Williams]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

Thank you very much!!

BTW, I solved stability and performance problems by lowering the memory 
setting ro 430M, using the 2.4.20 UML kernel, still with my 2.6.1+skas3 
host, and getting around to TMPDIR=/dev/shm (doh!).

If I can build in everything I need by rebuilding a kernel, I can live 
without modules.  In particular, I need IPv6, IPSec, and other advanced 
networking.

sdw

Gerd Knorr wrote:

>"Stephen D. Williams" <sdw@lig.net> writes:
>
>  
>
>>I would like 2.6.1 as a UML kernel along with support for >512 UML ram
>>and preferrably modules.  What is the best I can get right now?
>>
>>I'm running Gerd/SuSE's 2.6.0-test9,
>>    
>>
>
>ftp://ftp.suse.com/pub/people/kraxel/i386/ has 2.6.1 rpms since a few
>hours.  Both binary and source rpms, both uml and host, host with
>skas3, all building out a single source tree.  Modules don't work yet
>through.
>
>  Gerd
>
>  
>


-- 
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


[-- Attachment #2: sdw.vcf --]
[-- Type: text/x-vcard, Size: 234 bytes --]

begin:vcard
fn:Stephen Williams
n:Williams;Stephen
email;internet:sdw@lig.net
tel;work:703-724-0118
tel;fax:703-995-0407
tel;pager:sdwpage@lig.net
tel;home:703-729-5405
tel;cell:703-371-9362
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: [uml-devel] What is the most up to date, least crashing kernel+patch?

[Adam Heath]

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).




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] What is the most up to date, least crashing kernel+patch?

[Stephen D. Williams]

[-- Attachment #1: Type: text/plain, Size: 2408 bytes --]

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


[-- Attachment #2: sdw.vcf --]
[-- Type: text/x-vcard, Size: 234 bytes --]

begin:vcard
fn:Stephen Williams
n:Williams;Stephen
email;internet:sdw@lig.net
tel;work:703-724-0118
tel;fax:703-995-0407
tel;pager:sdwpage@lig.net
tel;home:703-729-5405
tel;cell:703-371-9362
x-mozilla-html:TRUE
version:2.1
end:vcard