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
prev parent 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.