From: Sven K. <sve...@gm...> - 2003-06-01 10:46:48
|
Hi Bruce, I did. But he's doing OpenMosix inside UML. What I am trying to do is to load balance one and the same UML-instance on several hardware (pysical) OpenMosix-nodes in a cluster (that's the other way round ;-). That is, this UML-instance would be migrated from one node to another depending on it's current cpu demand. So, Matt's code can't help me, I think. Thanks, Sven *********** REPLY SEPARATOR *********** On 31.05.2003 at 19:56 Bruce Knox wrote: >Hi Sven, have you seen Matt's >http://www.mosixview.com/umopenmosix/umopenmosix.html ? Bruce > > >>>> "Sven Kretzschmar" <sve...@gm...> 05/31/03 06:07PM >>> >Ok, found out some parts now: >With UML the whole VM of the UML instance is mapped to 'invisible' >file(s) in the /tmp directory (this dir can also be mounted as tmpfs :). >Every write / read to memory inside the UML might access >this mapped file in /tmp.... >However, I think it might still be possible with some patches >to let the deputy serve the missing pages to the slave. >Another special, UML-only possibility, might be to freeze the UML before > migrating it (there's already a possibility to do that, I think, via >UML-sysrq to >halt an UML and sync it), and copy it's whole memory mapped >space over to a new /tmp-file at the slave's node (no-go for diskless >nodes). >Then let the UML continue at the slave node with his new mmapped mem. >now on the slave. Of course, UMLs should not be migrated to often ;-) >Only some rough thoughts. Any comments on this ? > >TIA, > Sven > > >"Sven Kretzschmar" <sve...@gm...> schrieb >im Newsbeitrag news:bbb6ae$vdh$1...@ma...... >> I also have the cantmove - monkey problem. >> I tried to load-balance UML (user mode linux) instances in (old) tt= mode. >> (I am not trying to run openmosix inside UML, but the other way round !) >> Every process I start inside UML seems to be regarded as monkey process >> outside the UML by OpenMosix. >> (with tt-mode every process inside the UML gets a 'shadow process' in >kernel >> space). >> Which file is memory-mapped here ? Perhaps the root fs. >> Why can't openmosix try to move memory mapped files somehow ? >> I think bproc does that (with some tricks and only libs, I know). >> Can't the slave process on the slave node do this somehow (by requesting >> missing memory-mapped files' mem pages from the deputy - too much= traffic >?) >> ?? >> >> I also tried to apply the skas.v3-host patch to the host kernel but as >> expected, the patch >> had conflicts with openmosix (in mm/mmap.c and >arch/i386/kernel/sys_i386.c). >> >> I somehow have the vision of generating a cluster with many= UML-instances >> running on it. This would result in a lot of load-balanced virtual linux >> boxes. >> People could log in these virtual boxes with root rights and the admins >> would >> not have to care so much where the UML instances are running currently >and >> if the physical box it's running on has enough 'power' (if not, it's >> migrated automagically)... >> Perhaps this thought is too daring ;-) ? >> Has anybody tried this before with UML and OpenMosix ? >> >> TIA + Regards, >> Sven >> >> >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: eBay >> Get office equipment for less on eBay! >> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > > > > > >------------------------------------------------------- >This SF.net email is sponsored by: eBay >Get office equipment for less on eBay! >http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 >_______________________________________________ >openMosix-general mailing list >ope...@li... >https://lists.sourceforge.net/lists/listinfo/openmosix-general |
From: Peter B. <pe...@ra...> - 2003-06-01 21:16:24
|
On a few occasions now I have noticed the host CPU being pegged at 100% for a long period of time. Upon investigation I've found a vim (the editor) process chewing up the CPU. In most cases I think that the user session had terminated and vim has kept running. I've never seen this in machines not running UML, so I'm wondering if this is somehow UML specific behavior. Has anyone seen this before? Or have any idea what might be causing the problem? Or have any ideas how I could get a better fix on what is going wrong? I'm running the skas3 patch on the host. And 2.4.20-5um on the UML. TIA Peter |
From: Net Llama! <net...@li...> - 2003-06-01 21:23:40
|
I've seen this too, and have been rather puzzled by it. On 06/01/03 14:15, Peter Bryant wrote: > On a few occasions now I have noticed the host CPU being pegged at 100% for > a long period of time. > > Upon investigation I've found a vim (the editor) process chewing up the CPU. > In most cases I think that the user session had terminated and vim has kept > running. > > I've never seen this in machines not running UML, so I'm wondering if this > is somehow UML specific behavior. > > Has anyone seen this before? Or have any idea what might be causing the > problem? Or have any ideas how I could get a better fix on what is going > wrong? > > I'm running the skas3 patch on the host. And 2.4.20-5um on the UML. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman net...@li... Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 2:20pm up 1 day, 22:36, 1 user, load average: 0.19, 0.73, 0.99 |
From: Eric L. <er...@re...> - 2003-06-01 21:48:03
|
On Sun, 2003-06-01 at 23:15, Peter Bryant wrote: > Has anyone seen this before?=20 I frequently see this on standard hosts. So I don't think it's UML related. BR, --=20 Eric Leblond <er...@re...> |
From: Peter B. <pe...@ra...> - 2003-06-02 00:36:47
|
OK. Apparently the problem is caused by a Python module: http://vimdoc.sourceforge.net/cgi-bin/vimfaq2html3.pl The fix seems to be to build VIM without that module... > -----Original Message----- > From: use...@li... > [mailto:use...@li...]On Behalf Of > Eric Leblond > Sent: Sunday, June 01, 2003 2:48 PM > To: use...@li... > Subject: Re: [uml-user] VIM and CPU Usage > > > On Sun, 2003-06-01 at 23:15, Peter Bryant wrote: > > > Has anyone seen this before? > > I frequently see this on standard hosts. So I don't think it's UML > related. > > BR, > -- > Eric Leblond <er...@re...> > |
From: James S. <ja...@st...> - 2003-06-01 21:55:16
|
> > I've never seen this in machines not running UML, so I'm wondering if this > is somehow UML specific behavior. I have seen this on machine not running uml as in linux on an x86 it tends to happen if you have vim running in a telnet session from windows or something and you hit the X in the top right hand corner :) James |
From: Malcolm T. <ma...@co...> - 2003-06-01 23:48:26
|
On Mon, 2003-06-02 at 08:58, James Stevenson wrote: > > > > I've never seen this in machines not running UML, so I'm wondering if this > > is somehow UML specific behavior. > > I have seen this on machine not running uml as in linux on an x86 > it tends to happen if you have vim running in a telnet session > from windows or something and you hit the X in the top right hand corner > :) This is a fairly common problem with some terminal-based applications (mutt and vim being two common cases where it is seen) -- and it's not UML specific. If the controlling terminal terminates, sometimes the underlying application does not receive the appropriate signal correctly and continues to run. The 100% CPU usage is it polling away madly at stdin and stdout trying to work out what is going on the terminal. This is a genuine problem if you are doing remote administration on machines over a flaky connection: if the connection fails while you are editing a file, you had better make serious attempts to log back in and check that vim really terminated or your performance is going to suffer. :-( Cheers, Malcolm |
From: Net Llama! <net...@li...> - 2003-06-02 00:09:06
|
On 06/01/03 16:48, Malcolm Tredinnick wrote: > On Mon, 2003-06-02 at 08:58, James Stevenson wrote: >> > >> > I've never seen this in machines not running UML, so I'm wondering if this >> > is somehow UML specific behavior. >> >> I have seen this on machine not running uml as in linux on an x86 >> it tends to happen if you have vim running in a telnet session >> from windows or something and you hit the X in the top right hand corner >> :) > > This is a fairly common problem with some terminal-based applications > (mutt and vim being two common cases where it is seen) -- and it's not > UML specific. If the controlling terminal terminates, sometimes the > underlying application does not receive the appropriate signal correctly > and continues to run. The 100% CPU usage is it polling away madly at > stdin and stdout trying to work out what is going on the terminal. > > This is a genuine problem if you are doing remote administration on > machines over a flaky connection: if the connection fails while you are > editing a file, you had better make serious attempts to log back in and > check that vim really terminated or your performance is going to suffer. This isn't an issue of vim not terminating cleanly. This happens when vim is still in use, in my experience. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman net...@li... Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 5:05pm up 2 days, 1:21, 1 user, load average: 0.05, 0.07, 0.08 |
From: Cees de G. <cg...@cd...> - 2003-06-02 07:11:55
|
On Mon, 2003-06-02 at 01:48, Malcolm Tredinnick wrote: > This is a genuine problem if you are doing remote administration on > machines over a flaky connection: if the connection fails while you are > editing a file, you had better make serious attempts to log back in and > check that vim really terminated or your performance is going to suffer. > :-( > For remote administration over flaky connections (try a Nokia Communicator over GSM out in the woods ;-)), ``screen'' is your friend. -- Disclaimer: all Dutchmen are liars |
From: Vincent T. <vi...@ul...> - 2003-06-02 07:25:30
|
On Mon, Jun 02, 2003 at 09:48:21AM +1000, Malcolm Tredinnick wrote: >This is a genuine problem if you are doing remote administration on >machines over a flaky connection: if the connection fails while you are >editing a file, you had better make serious attempts to log back in and >check that vim really terminated or your performance is going to suffer. >:-( Could screen help out in this case ? I suppose it will keep the environment for the remote app, even if your connection fails, so you would be able to resume upon logging back in. No need for mad polling then as stdin and stdout are still properly connected ? regards v |