Menu
▾
▴
colinux-devel
|
From: Axel J. <je...@MP...> - 2004-04-14 09:52:08
|
Hello everyone,
I am finding coLinux allready an extremely useful and productive way to help me use the best of both the Linux and
Win-world. I am running it on a WIN2K Laptop (1 GB RAM and 2 GHz clock) where both are stable.
Problem a.
I made an overnight test using my own software to create an index of several 10k binary raw data files residing in roughly two
hundred directories on an external 160 GB USB masstorage drive. This meant finding, opening reading each file and writing some
catalogue information to a text file.
All in all this were about 90 GB of data. The programme started to execute quickly and efficiently but in the next morning it
had ground to slow crawl. I found that everthing was swapped out and and swap-use continued to increase.
I then found that even without the programme running, with a constant number of idle processes, free memory is slowly eaten
up at about 100kB per minute. I attached two successive "top-results" to this mail. Apparently the reservation for Buffer
increases regularely and this is taken away from free mem. Comparing that to a another (RedHat two-cpus) system I find
that bufferspace also increases there, but not to the detriment of free mem. Could there be a problem with memory garbage
collection in colinux? Or can that be remedied in another way?
Problem b.
One of the great and ingenious advantages of coLinux and its interface to WIN is the fact that one can mount nearly all devices
that WIN can mount, including i.e. masstorage on the WIN-USB ports either as flash memory sticks or big external
disks. Nice is the facility to mount even more than WIN, i.e. the reiser partions on which the alternat boot Linux resides.
This is normally not accessible by WIN. Please include it in the next kernel release as compiled in, if possible.
Only the UDF-Packet format for CD-RWs posing as external RW-drives doesn't work, but this isn't supported by ordinary
Linux either. In colinux I encounter a limitation in the number of /dev/cobd slots that can be allocated. On bootup the
console message say eight are supported, but there are only four /dev/cobd0-3. I could not find the location whre this limit
is set, nor could I increase the number of cobd in any other way. Does that depend on the kernel or on the debian
base image?
I am truly grateful for the superb ideas and all the work you have put into the colinux development, it is certainly better
and more useful that VMware which was quite troublesome so that we don't use it much any more.
cheers
Axel Jessner
>>>>>>>>>>>>>>>>>>>>>>>>>>>> after boot and login via ssh
11:10:30 up 0 min, 1 user, load average: 0.07, 0.03, 0.01
32 processes: 30 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 0.0% user, 0.0% system, 0.0% nice, 100.0% idle
Mem: 94540K total, 18324K used, 76216K free, 1844K buffers
Swap: 262136K total, 0K used, 262136K free, 8604K cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
1 root 7 0 484 484 424 S 0.0 0.5 0:00 init
2 root 9 0 0 0 0 SW 0.0 0.0 0:00 keventd
3 root 19 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0
4 root 9 0 0 0 0 SW 0.0 0.0 0:00 kswapd
5 root 9 0 0 0 0 SW 0.0 0.0 0:00 bdflush
6 root 9 0 0 0 0 SW 0.0 0.0 0:00 kupdated
7 root 9 0 0 0 0 SW 0.0 0.0 0:00 kjournald
64 root 9 0 0 0 0 SW 0.0 0.0 0:00 kreiserfsd
88 daemon 9 0 416 416 344 S 0.0 0.4 0:00 portmap
148 root 9 0 780 780 664 S 0.0 0.8 0:00 syslogd
151 root 9 0 508 508 380 S 0.0 0.5 0:00 klogd
163 root 9 0 728 728 644 S 0.0 0.7 0:00 inetd
167 root 9 0 744 744 652 S 0.0 0.7 0:00 lpd
173 root 9 0 1204 1204 768 S 0.0 1.2 0:00 nmbd
181 root 9 0 1240 1240 768 S 0.0 1.3 0:00 smbd
194 root 10 0 1280 1280 1156 S 0.0 1.3 0:00 sshd
197 daemon 9 0 580 580 504 S 0.0 0.6 0:00 atd
200 root 9 0 684 684 564 S 0.0 0.7 0:00 cron
212 root 9 0 468 468 408 S 0.0 0.4 0:00 getty
213 root 9 0 468 468 408 S 0.0 0.4 0:00 getty
214 root 9 0 468 468 408 S 0.0 0.4 0:00 getty
215 root 9 0 468 468 408 S 0.0 0.4 0:00 getty
216 root 9 0 468 468 408 S 0.0 0.4 0:00 getty
230 root 10 0 468 468 408 S 0.0 0.4 0:00 getty
242 root 10 0 1832 1832 1676 S 0.0 1.9 0:00 sshd
244 jessner 14 0 1936 1936 1736 R 0.0 2.0 0:00 sshd
245 jessner 11 0 1036 1036 764 S 0.0 1.0 0:00 tcsh
246 jessner 11 0 816 816 644 S 0.0 0.8 0:00 sftp-server
247 jessner 13 0 1036 1036 764 S 0.0 1.0 0:00 tcsh
248 jessner 13 0 1480 1480 960 S 0.0 1.5 0:00 tcsh
249 jessner 13 0 816 816 644 S 0.0 0.8 0:00 sftp-server
250 jessner 14 0 932 932 748 R 0.0 0.9 0:00 top
>>>>>>>>>>>>>>>>>>> After 1 minute
11:11:20 up 1 min, 1 user, load average: 0.03, 0.02, 0.00
32 processes: 30 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 0.2% user, 0.0% system, 0.0% nice, 99.8% idle
Mem: 94540K total, 18412K used, 76128K free, 1932K buffers
Swap: 262136K total, 0K used, 262136K free, 8604K cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
244 jessner 15 0 1936 1936 1736 R 0.1 2.0 0:00 sshd
1 root 8 0 484 484 424 S 0.0 0.5 0:00 init
2 root 9 0 0 0 0 SW 0.0 0.0 0:00 keventd
3 root 19 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0
4 root 9 0 0 0 0 SW 0.0 0.0 0:00 kswapd
5 root 9 0 0 0 0 SW 0.0 0.0 0:00 bdflush
6 root 9 0 0 0 0 SW 0.0 0.0 0:00 kupdated
7 root 9 0 0 0 0 SW 0.0 0.0 0:00 kjournald
64 root 9 0 0 0 0 SW 0.0 0.0 0:00 kreiserfsd
88 daemon 9 0 416 416 344 S 0.0 0.4 0:00 portmap
148 root 9 0 780 780 664 S 0.0 0.8 0:00 syslogd
151 root 9 0 508 508 380 S 0.0 0.5 0:00 klogd
163 root 9 0 728 728 644 S 0.0 0.7 0:00 inetd
167 root 9 0 744 744 652 S 0.0 0.7 0:00 lpd
173 root 9 0 1204 1204 768 S 0.0 1.2 0:00 nmbd
181 root 9 0 1240 1240 768 S 0.0 1.3 0:00 smbd
194 root 9 0 1280 1280 1156 S 0.0 1.3 0:00 sshd
197 daemon 9 0 580 580 504 S 0.0 0.6 0:00 atd
200 root 9 0 684 684 564 S 0.0 0.7 0:00 cron
212 root 9 0 468 468 408 S 0.0 0.4 0:00 getty
213 root 9 0 468 468 408 S 0.0 0.4 0:00 getty
214 root 9 0 468 468 408 S 0.0 0.4 0:00 getty
215 root 9 0 468 468 408 S 0.0 0.4 0:00 getty
216 root 9 0 468 468 408 S 0.0 0.4 0:00 getty
230 root 9 0 468 468 408 S 0.0 0.4 0:00 getty
242 root 9 0 1832 1832 1676 S 0.0 1.9 0:00 sshd
245 jessner 10 0 1036 1036 764 S 0.0 1.0 0:00 tcsh
246 jessner 10 0 816 816 644 S 0.0 0.8 0:00 sftp-server
247 jessner 11 0 1036 1036 764 S 0.0 1.0 0:00 tcsh
248 jessner 11 0 1480 1480 960 S 0.0 1.5 0:00 tcsh
249 jessner 11 0 816 816 644 S 0.0 0.8 0:00 sftp-server
250 jessner 11 0 932 932 748 R 0.0 0.9 0:00 top
--
----------------------------------------------------------------
Dr. Axel Jessner
MPIfR Radioobservatory Effelsberg
D-53902 Bad Muenstereifel
Phone: Germany (0)2257-301-127
FAX: (0)2257-301-105
----------------------------------------------------------------
|
|
From: Dan A. <da...@co...> - 2004-04-14 10:42:21
|
On Wed, Apr 14, 2004 at 11:52:21AM +0200, Axel Jessner wrote: > Hello everyone, > > I am finding coLinux allready an extremely useful and productive way to help me use the best of both the Linux and > Win-world. I am running it on a WIN2K Laptop (1 GB RAM and 2 GHz clock) where both are stable. > > Problem a. > I made an overnight test using my own software to create an index of several 10k binary raw data files residing in roughly two > hundred directories on an external 160 GB USB masstorage drive. This meant finding, opening reading each file and writing some > catalogue information to a text file. > All in all this were about 90 GB of data. The programme started to execute quickly and efficiently but in the next morning it > had ground to slow crawl. I found that everthing was swapped out and and swap-use continued to increase. Did you rule out the possiblity that your userspace program has a leak, and not the kernel? Unless you see lines such as '__alloc_pages: 0-order allocation failed', chances are there was no kernel memory leak. The symptoms you describe fit more to the case where a userspace program eats up too much memory. > I then found that even without the programme running, with a constant number of idle processes, free memory is slowly eaten > up at about 100kB per minute. I attached two successive "top-results" to this mail. Apparently the reservation for Buffer > increases regularely and this is taken away from free mem. Comparing that to a another (RedHat two-cpus) system I find > that bufferspace also increases there, but not to the detriment of free mem. Could there be a problem with memory garbage > collection in colinux? Or can that be remedied in another way? On normal conditions pages of the buffer cache is freed at some point. I've ran a few tests on coLinux and it clearly shows that it gets freed. > Problem b. > One of the great and ingenious advantages of coLinux and its interface to WIN is the fact that one can mount nearly all devices > that WIN can mount, including i.e. masstorage on the WIN-USB ports either as flash memory sticks or big external > disks. Nice is the facility to mount even more than WIN, i.e. the reiser partions on which the alternat boot Linux resides. > This is normally not accessible by WIN. Please include it in the next kernel release as compiled in, if possible. > Only the UDF-Packet format for CD-RWs posing as external RW-drives doesn't work, but this isn't supported by ordinary > Linux either. In colinux I encounter a limitation in the number of /dev/cobd slots that can be allocated. On bootup the > console message say eight are supported, but there are only four /dev/cobd0-3. I could not find the location whre this limit > is set, nor could I increase the number of cobd in any other way. Does that depend on the kernel or on the debian > base image? You can create the device node numbers for the other 4 devices using mknod (1). About the 8 limit, it is semi-hard-coded at the moment, will be taken care of in the next release. -- Dan Aloni da...@co... |
|
From: Eugene T. <eug...@eu...> - 2004-04-14 10:53:14
|
<quote sender="Dan Aloni"> > On Wed, Apr 14, 2004 at 11:52:21AM +0200, Axel Jessner wrote: > > Hello everyone, > > > > I am finding coLinux allready an extremely useful and productive way to help me use the best of both the Linux and > > Win-world. I am running it on a WIN2K Laptop (1 GB RAM and 2 GHz clock) where both are stable. > > > > Problem a. > > I made an overnight test using my own software to create an index of several 10k binary raw data files residing in roughly two > > hundred directories on an external 160 GB USB masstorage drive. This meant finding, opening reading each file and writing some > > catalogue information to a text file. > > All in all this were about 90 GB of data. The programme started to execute quickly and efficiently but in the next morning it > > had ground to slow crawl. I found that everthing was swapped out and and swap-use continued to increase. > > Did you rule out the possiblity that your userspace program has a leak, > and not the kernel? Unless you see lines such as '__alloc_pages: 0-order > allocation failed', chances are there was no kernel memory leak. > The symptoms you describe fit more to the case where a userspace > program eats up too much memory. even if you get to see such lines '__alloc_pages: 0-order allocation failed', it does not mean that there is a kernel memory leak. That could mean that the memory is trying really hard to accomodate and allocate memory under a really bad pressure. It is interesting to see such behaviour though. I would suggest Axel do a simpler test to see if it is indeed your userspace application that is causing this problem. Eugene -- Eugene TEO - <eugeneteo%null!cc!uic!edu> <http://www.anomalistic.org/> 1024D/14A0DDE5 print D851 4574 E357 469C D308 A01E 7321 A38A 14A0 DDE5 main(i) { putchar(182623909 >> (i-1) * 5&31|!!(i<7)<<6) && main(++i); } |
|
From: Dan A. <da...@co...> - 2004-04-14 11:10:09
|
On Wed, Apr 14, 2004 at 06:53:01PM +0800, Eugene Teo wrote: > <quote sender="Dan Aloni"> > > On Wed, Apr 14, 2004 at 11:52:21AM +0200, Axel Jessner wrote: > > > Hello everyone, > > > > > > I am finding coLinux allready an extremely useful and productive way to help me use the best of both the Linux and > > > Win-world. I am running it on a WIN2K Laptop (1 GB RAM and 2 GHz clock) where both are stable. > > > > > > Problem a. > > > I made an overnight test using my own software to create an index of several 10k binary raw data files residing in roughly two > > > hundred directories on an external 160 GB USB masstorage drive. This meant finding, opening reading each file and writing some > > > catalogue information to a text file. > > > All in all this were about 90 GB of data. The programme started to execute quickly and efficiently but in the next morning it > > > had ground to slow crawl. I found that everthing was swapped out and and swap-use continued to increase. > > > > Did you rule out the possiblity that your userspace program has a leak, > > and not the kernel? Unless you see lines such as '__alloc_pages: 0-order > > allocation failed', chances are there was no kernel memory leak. > > The symptoms you describe fit more to the case where a userspace > > program eats up too much memory. > > even if you get to see such lines '__alloc_pages: 0-order allocation > failed', it does not mean that there is a kernel memory leak. That could > mean that the memory is trying really hard to accomodate and allocate > memory under a really bad pressure. The situation you are describing is more likely to occur when no swap is installed, but that's not the case here. -- Dan Aloni da...@co... |
|
From: Dan A. <da...@co...> - 2004-04-14 11:35:55
|
On Wed, Apr 14, 2004 at 01:24:15PM +0200, Axel Jessner wrote: > No, I cannot rule out a problem with my own userspace program (made with fpc). :-) > But the leak happens without any of my contributions. It could be another process. Perhaps you should try to tackle it a bit more. > I did do a very simple test and rebooted colinux, only ran top onm the console. The problem does persist (see attached > snapshots). > > Since the beginning, under all kernel versions and configurations, on booting I get the following boot message: > > EXT3 FS 2.4-0.9.19, 19 August 2002 on cobd(117,0), internal journal > EXT3-fs: mounted filesystem with ordered data mode. > VFS: Mounted root (ext3 filesystem). > Freeing unused kernel memory: IMPLEMENTATION MISSING <==== > EXT3 FS 2.4-0.9.19, 19 August 2002 on cobd(117,0), internal journal > > could that point to the cause? This has nothing to do with it. That message is about initmem not being freed, which is annoying but harmless. -- Dan Aloni da...@co... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X