Re: 2.6.11.12-om low max bandwidth
Peter Cordes <[email protected]>
| Newsgroups | gmane.linux.cluster.openmosix.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sun, Sep 18, 2005 at 01:29:40PM +0300, thunderlord wrote: > Hi again! > > I understand that using a global cluster filesystem would be a great > choice, but for my small cluster of 2, maybe 3 nodes I think it is not > necessary. I just want to speed up data transfer between stub process on > home node and worker process on another node. Currently it looks like > some bandwidth limit is set for each migrated process, limiting > bandwidth to 800-900 Kbit/s, so the only way to make my 935Mhz Duron to > work at ~99% CPU usage is to migrate enough processes, then overall > badwidth grows in arithmetic progression, but this is not always acceptable. > *So my question is: does anybody know where in kernel code could be such > a function/piece of code that limits data transfer rates between > stub(deputy) process (which fetches data from harddisk on home node) and > worker process on another node?* My guess is that oM doesn't pipeline or readahead (sufficiently? if at all). It's not that anything is on purpose limiting transer rate, but rather that it doesn't ask for things ahead of time, so your process spends a network RTT (round trip time) waiting. This probably isn't easy to get around in oM, because oM just relays system calls, and pipelining a read of a big file would require oM on the remote side to handle the read system call locally after prefetching the data. That opens up the whole can of worms that goes with NFS and caching semantics... DFSA might have done something like this on 2.4 oM. I don't use 2.6 om, so I'm getting out of my depth here with speculations. > I analized changes that openmosix patch make to vanilla kernel code and > found several possible places, but to test them all can take a lot of > time, because i am not so good in kernel development, and do not know > openmosix kernel code good enough. -- #define X(x,y) x##y Peter Cordes ; e-mail: X(peter@cor , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php