All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stephen D. Williams" <sdw@lig.net>
To: Adam Heath <adam@doogie.org>
Cc: user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] What is the most up to date, least crashing kernel+patch?
Date: Sat, 17 Jan 2004 13:25:17 -0500	[thread overview]
Message-ID: <40097E0D.6020504@lig.net> (raw)
In-Reply-To: <Pine.LNX.4.44.0401171208310.23425-100000@yakko.doogie.org>

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


      reply	other threads:[~2004-01-17 18:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-17  3:11 [uml-devel] What is the most up to date, least crashing kernel+patch? Stephen D. Williams
2004-01-17 10:53 ` [uml-devel] " Gerd Knorr
2004-01-17 15:31   ` Stephen D. Williams
2004-01-17 18:12 ` [uml-devel] " Adam Heath
2004-01-17 18:25   ` Stephen D. Williams [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40097E0D.6020504@lig.net \
    --to=sdw@lig.net \
    --cc=adam@doogie.org \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.