Unoffical empeg BBS

Quick Links: Empeg FAQ | RioCar.Org | Hijack | BigDisk Builder | jEmplode | emphatic
Repairs: Repairs

Topic Options
#18638 - 26/09/2000 01:47 VM: killing process xyz
Blacksun
new poster

Registered: 01/05/2000
Posts: 17
Hi there

Does some one know what is always killing my Demons?
I start some Demons, before I start the player. When I want to login with Telnet for ex. the following message is displayed via the serial line:

VM: killing process in.telnetd

Or after I connected for some time to the empeg with Windows I get a message:

VM: killing process smbd

Can I stop the VM to kill my Demons?

regards Mirko

.: i love my empeg!!
_________________________
.: i love my empeg!!

Top
#18639 - 26/09/2000 03:02 Re: VM: killing process xyz [Re: Blacksun]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5681
Loc: London, UK
No. You can't.

"VM: killing process xyz" means that the OS has run out of memory. It randomly picks a process to kill.

We don't advise running any daemons while the player binary is running, because the player binary assumes that it has the entire machine to itself, and simply allocates the full 12Mb (minus a bit for the kernel) on a mk2.


Roger - not necessarily speaking for empeg
_________________________
-- roger

Top
#18640 - 26/09/2000 03:03 Re: VM: killing process xyz [Re: Blacksun]
kim
member

Registered: 21/07/1999
Posts: 140
Loc: Helsinki, Finland
Does some one know what is always killing my Demons?
I start some Demons, before I start the player. When I want to login with Telnet for ex. the following message is displayed via the serial line:

VM: killing process in.telnetd


empeg-player allocates all memory to itself (for caching) and disables paging which results the virtual memory manager to kill processes as it's running out of memory.

You can add the following block to /empeg/var/config.ini file:
[Startup]
ReserveCache=32


This will prevent the empeg-player to allocate all memory to itself, leaving ReserveCache*32KB of memory to user-space applications (if I recall right). So, in the case above, it will leave 1MB of memory for other applications.

Naturally, the higher the value is, the more frequently it'll spin up the disk and cache data, but I've found values from 4-64 to work fairly well on my Mk2.

Kim


Top
#18641 - 27/09/2000 12:25 Re: VM: killing process xyz [Re: Roger]
Blacksun
new poster

Registered: 01/05/2000
Posts: 17
Are there some plans to make the player software a little bit "nicer" (nicer => Unix nice command) to support parallel user applications and rw support on the disks?

regards Mirko



.: i love my empeg!!
_________________________
.: i love my empeg!!

Top
#18642 - 27/09/2000 12:32 Re: VM: killing process xyz [Re: Blacksun]
rob
carpal tunnel

Registered: 21/05/1999
Posts: 5335
Loc: Cambridge UK
The player HAS to be ruthless to do its job. Playback cannot be allowed to glitch for even a fraction of a second and mounting the disks rw in the car is a bad idea. Even leaving them spun up the whole time is less than ideal.

As with empeg-written threads which perform a variety of functions within the player, user written applications are going to have to conform with strict guidelines to allow the product to do its primary task effectively.

Rob



Top
#18643 - 27/09/2000 12:39 Re: VM: killing process xyz [Re: Blacksun]
fvgestel
old hand

Registered: 12/08/2000
Posts: 702
Loc: Netherlands
I solved this problem by activating some swap space...
look at my init script for details...


#!/bin/bash
#
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/roo
t/bin:/usr/local/root/sbin
TERM=vt100
export PATH TERM
IMGDIR=/usr/local/images
mount -n -o remount,ro /
/bin/mount -n -o nocheck,rw /proc
/bin/mount -n -o nocheck,ro /dev/hda4 /drive0
INETD=0
RW=0
while :
do
/empeg/bin/player
if grep -q '0 (AC Power)' /proc/empeg_power
then
if [ "$RW" = "0" ]
then
echo "Mounting readwrite"
blitraw < $IMGDIR/readwrite.raw
mount -n -o remount,rw /
mount -n -o remount,rw /drive0
echo "Activating swap"
blitraw < $IMGDIR/swapon.raw
sleep 1
swapon /usr/local/root/swapfile
RW=1
hostname empeg
if [ "$INETD" = "0" ]
then
blitraw < $IMGDIR/inetd.raw
echo "Starting inetd"
sleep 1
/sbin/inetd
INETD=1
/usr/local/sbin/fidstreamer&
fi
else
blitraw < $IMGDIR/swapoff.raw
echo "Turning off swap"
sleep 1
swapoff /usr/local/root/swapfile
blitraw < $IMGDIR/readonly.raw
echo "Mounting readonly"
sleep 1
mount -n -o remount,ro /
mount -n -o remount,ro /drive0
RW=0
fi
fi
echo "Press q to terminate to a shell"
/usr/local/sbin/getkey q && /bin/bash
if [ -f /var/run/player.norun ]
then
read DUMMY
fi
done


maybe you could start /empeg/bin/player with a nice value
like :

nice 19 /empeg/bin/player

but I haven't tried that yet...

I activated the quit=1 option in the ini file. so when I quit player, it will switch from rw to ro and so on. Inetd is only started once, but I cannot seem to telnet in if the partition is mounted ro

Frank van Gestel
_________________________
Frank van Gestel

Top
#18644 - 28/09/2000 01:11 Re: VM: killing process xyz [Re: rob]
Blacksun
new poster

Registered: 01/05/2000
Posts: 17
Why is mounting the disk rw in the Car a bad Idea? Right now I am installing the empeg with Wireless Lan and I currently write a Empeg specific HTTP Demon, which understands the empeg database and configuration files. But I don't understand why the empeg mounts the drives ro?

regards Mirko

.: i love my empeg!!
_________________________
.: i love my empeg!!

Top
#18645 - 28/09/2000 01:19 Re: VM: killing process xyz [Re: fvgestel]
Blacksun
new poster

Registered: 01/05/2000
Posts: 17
Hi Frank

Thank's for your detailed information. You did some great work in your init script. I'll try to implement it on my empeg.
I think starting the player software with the nice command wouldn't work, because the empeg player uses a lot of realtime, interrupt based code. (Not really sure!)

Thanks, regards Mirko


.: i love my empeg!!
_________________________
.: i love my empeg!!

Top
#18646 - 28/09/2000 02:28 Re: VM: killing process xyz [Re: Blacksun]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5681
Loc: London, UK
Because if it's mounted rw, we can't guarantee that something won't be writing to the disk when you yank the power.

Even if this doesn't occur, yanking the power will cause an fsck at the next opportunity, which takes quite a while.


Roger - not necessarily speaking for empeg
_________________________
-- roger

Top
#18647 - 28/09/2000 04:02 Re: VM: killing process xyz [Re: fvgestel]
kim
member

Registered: 21/07/1999
Posts: 140
Loc: Helsinki, Finland
I solved this problem by activating some swap space...

Weird... empeg-player should disable paging which means that no swapping can happen while the player is running - so in theory it shouldn't have an effect. (Unless you increased the ReserveCache variable, which is different thing)

maybe you could start /empeg/bin/player with a nice value
like :

nice 19 /empeg/bin/player


...does not have any effect either. nice only modifies dynamic priorities of default Linux time-sharing threads while empeg-player uses real-time scheduling.

Kim



Top
#18648 - 28/09/2000 06:11 Re: VM: killing process xyz [Re: kim]
fvgestel
old hand

Registered: 12/08/2000
Posts: 702
Loc: Netherlands
I also think that the player process will not swap out, but other tasks can and will . See the output of top :

1:00pm up 1:20, 3 users, load average: 0.78, 0.48, 0.58
25 processes: 24 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 24.9% user, 3.1% system, 0.0% nice, 71.8% idle
Mem: 10888K av, 10624K used, 264K free, 1436K shrd, 248K buff
Swap: 16380K av, 1760K used, 14620K free 1768K cached

PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
229 root 2 0 8232 8232 988 S 0 37.3 75.6 0:04 player
232 root 5 0 584 520 436 R 0 7.8 4.7 0:00 top
231 root 1 0 8232 8232 988 S 0 2.7 75.6 0:00 player
227 root 0 0 8232 8232 988 S 0 0.5 75.6 0:02 player
1 root 0 0 180 0 0 SW 0 0.0 0.0 0:04 init
2 root 0 0 0 0 0 SW 0 0.0 0.0 0:06 kflushd
3 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kupdate
4 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kpiod
5 root 0 0 0 0 0 SW 0 0.0 0.0 0:07 kswapd
112 root 0 0 296 0 0 SW 0 0.0 0.0 0:04 bash
192 root 0 0 328 0 0 SW 0 0.0 0.0 0:00 mc
195 root 0 0 284 0 0 SW 0 0.0 0.0 0:00 bash
213 root 0 0 308 0 0 SW 0 0.0 0.0 0:00 mc
215 root 0 0 284 0 0 SW 0 0.0 0.0 0:00 bash
218 root 0 0 8232 8232 988 S 0 0.0 75.6 0:00 player
219 root 0 0 8232 8232 988 S 0 0.0 75.6 0:00 player
220 root 0 0 8232 8232 988 S 0 0.0 75.6 0:00 player



I also tried using nice to start the player :


1:11pm up 1:32, 3 users, load average: 1.08, 0.81, 0.66
25 processes: 24 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 35.6% user, 2.8% system, 0.0% nice, 61.4% idle
Mem: 10888K av, 10580K used, 308K free, 1332K shrd, 244K buff
Swap: 16380K av, 1812K used, 14568K free 1516K cached

PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
275 root -7 -10 8232 8232 988 S < 0 32.4 75.6 0:17 player
278 root 6 0 508 440 344 R 0 2.8 4.0 0:01 top
277 root -10 -10 8232 8232 988 S < 0 2.1 75.6 0:01 player
273 root -10 -10 8232 8232 988 S < 0 0.9 75.6 0:06 player
1 root 0 0 180 0 0 SW 0 0.0 0.0 0:04 init
2 root 0 0 0 0 0 SW 0 0.0 0.0 0:06 kflushd
3 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kupdate
4 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kpiod
5 root 0 0 0 0 0 SW 0 0.0 0.0 0:08 kswapd
112 root 0 0 296 0 0 SW 0 0.0 0.0 0:04 bash
192 root 0 0 328 0 0 SW 0 0.0 0.0 0:00 mc
195 root 0 0 284 0 0 SW 0 0.0 0.0 0:00 bash
213 root 0 0 308 0 0 SW 0 0.0 0.0 0:00 mc
215 root 0 0 344 0 0 SW 0 0.0 0.0 0:04 bash
264 root -10 -10 8232 8232 988 S < 0 0.0 75.6 0:00 player
265 root -10 -10 8232 8232 988 S < 0 0.0 75.6 0:00 player
266 root -10 -10 8232 8232 988 S < 0 0.0 75.6 0:00 player



I don't think it will do anything though.
Kim, do you have any more info about how the player executable is linked with the kernel.
I should think it will operate in user and in kernel mode.
Which part is embedded in kernel and which is handled by the kernel?

Frank van Gestel
_________________________
Frank van Gestel

Top
#18649 - 28/09/2000 06:22 Re: VM: killing process xyz [Re: fvgestel]
fvgestel
old hand

Registered: 12/08/2000
Posts: 702
Loc: Netherlands
I found that only the reading of the database is spent in true user mode. After that realtime scheduling is indeed enforced...

Frank van Gestel
_________________________
Frank van Gestel

Top
#18650 - 28/09/2000 06:38 Re: VM: killing process xyz [Re: fvgestel]
kim
member

Registered: 21/07/1999
Posts: 140
Loc: Helsinki, Finland
Kim, do you have any more info about how the player executable is linked with the kernel.
I should think it will operate in user and in kernel mode.
Which part is embedded in kernel and which is handled by the kernel?


I don't think there's any special kernel related in empeg-player, it just uses real-time scheduling (=SCHED_RR) instead of the default Linux time-sharing scheduling (=SCHED_OTHER) - see setscheduler(2).

As Rob pointed out, they want to have all the CPU power and memory efficiently used and in control of the player application to ensure that audio won't start skipping and visualizations start jerking. I understand this completely, though, as a 3rd party developer, I also see the other side of the coin. Anyhow, empeg primarily needs to ensure that their software runs smoothly on their hardware.

In theory, you can run process which also uses real-time scheduling and share the time with empeg-player, but then the application using real-time scheduling should really be designed for that. So it's likely that people won't end up running internet daemons while the player is running on background (not that there would even be free resources for it).

Kim


Top
#18651 - 28/09/2000 06:53 Re: VM: killing process xyz [Re: kim]
fvgestel
old hand

Registered: 12/08/2000
Posts: 702
Loc: Netherlands
Thanks, I've never seen any RT applications on linux before...
I also saw the mlockall call come by with strace :>

Frank van Gestel
_________________________
Frank van Gestel

Top
#18652 - 28/09/2000 09:01 Re: VM: killing process xyz [Re: kim]
altman
carpal tunnel

Registered: 19/05/1999
Posts: 3457
Loc: Palo Alto, CA
The player doesn't disable paging, it mlock()'s its pages into memory so they will not be paged out (this means that the drive won't spin up unless we request data from disk explicitly).

Hugo



Top