memx - Project Hosting on Google Code

Last 7 days Dec 24, 2009 r244 (why is it so hard to find the right makefile?) committed by michael@hinespot.net - why is it so hard to find the right makefile? why is it so hard to find the right makefile? Dec 23, 2009 r243 (branch:michael last one, I promise) committed by michael@hinespot.net - branch:michael last one, I promise branch:michael last one, I promise Dec 23, 2009 r242 (branch:michael oops) committed by michael@hinespot.net - branch:michael oops branch:michael oops Dec 23, 2009 r241 (branch:michael I don't think it's necessary to block kill, s...) committed by michael@hinespot.net - branch:michael I don't think it's necessary to block kill, stop, interrupt signals, but it seems to be necessary on physical machines when someone types ctrl-c branch:michael I don't think it's necessary to block kill, stop, interrupt signals, but it seems to be necessary on physical machines when someone types ctrl-c Dec 23, 2009 r240 (branch:michael cannot directly do 64-bit division in linux. ...) committed by michael@hinespot.net - branch:michael cannot directly do 64-bit division in linux. must use do_div branch:michael cannot directly do 64-bit division in linux. must use do_div Dec 23, 2009 r239 (branch:michael cannot directly do 64-bit division in linux. ...) committed by michael@hinespot.net - branch:michael cannot directly do 64-bit division in linux. must use do_div branch:michael cannot directly do 64-bit division in linux. must use do_div Dec 23, 2009 r238 (branch:michael cannot directly do 64-bit division in linux. ...) committed by michael@hinespot.net - branch:michael cannot directly do 64-bit division in linux. must use do_div branch:michael cannot directly do 64-bit division in linux. must use do_div Dec 23, 2009 r237 (branch:michael cannot directly do 64-bit division in linux. ...) committed by michael@hinespot.net - branch:michael cannot directly do 64-bit division in linux. must use do_div branch:michael cannot directly do 64-bit division in linux. must use do_div Dec 22, 2009 r236 (branch:michael separation between the client's flow control ...) committed by michael@hinespot.net - branch:michael separation between the client's flow control code and the protocol branch:michael separation between the client's flow control code and the protocol Dec 22, 2009 r235 (branch:michael separation between the client's flow control ...) committed by michael@hinespot.net - branch:michael separation between the client's flow control code and the protocol branch:michael separation between the client's flow control code and the protocol Dec 22, 2009 r234 (branch:michael separation between the client's flow control ...) committed by michael@hinespot.net - branch:michael separation between the client's flow control code and the protocol branch:michael separation between the client's flow control code and the protocol Dec 22, 2009 r233 (branch:michael pure separation between protocol and networki...) committed by michael@hinespot.net - branch:michael pure separation between protocol and networking functions. branch:michael pure separation between protocol and networking functions. Dec 22, 2009 r232 (branch:michael pure separation between protocol and networki...) committed by michael@hinespot.net - branch:michael pure separation between protocol and networking functions. branch:michael pure separation between protocol and networking functions. Last 30 days Dec 21, 2009 r231 (branch:michael pure separation between protocol and networki...) committed by michael@hinespot.net - branch:michael pure separation between protocol and networking functions. branch:michael pure separation between protocol and networking functions. Dec 20, 2009 r230 (branch:michael bug-fix version of transfer support.) committed by michael@hinespot.net - branch:michael bug-fix version of transfer support. branch:michael bug-fix version of transfer support. Dec 20, 2009 r229 (branch:michael bug-fix version of transfer support.) committed by michael@hinespot.net - branch:michael bug-fix version of transfer support. branch:michael bug-fix version of transfer support. Dec 20, 2009 r228 (branch:michael bug-fix version of transfer support.) committed by michael@hinespot.net - branch:michael bug-fix version of transfer support. branch:michael bug-fix version of transfer support. Dec 20, 2009 r227 (branch:michael bug-fix version of transfer support.) committed by michael@hinespot.net - branch:michael bug-fix version of transfer support. branch:michael bug-fix version of transfer support. Dec 20, 2009 r226 (branch:michael bug-fix version of transfer support.) committed by michael@hinespot.net - branch:michael bug-fix version of transfer support. branch:michael bug-fix version of transfer support. Dec 20, 2009 r225 (branch:michael bug-fix version of transfer support.) committed by michael@hinespot.net - branch:michael bug-fix version of transfer support. branch:michael bug-fix version of transfer support. Dec 16, 2009 r224 (branch:michael client transfers have some bugs in them, work...) committed by michael@hinespot.net - branch:michael client transfers have some bugs in them, working it out..... branch:michael client transfers have some bugs in them, working it out..... Dec 11, 2009 r223 (branch:michael preparing to move the server worker into net....) committed by michael@hinespot.net - branch:michael preparing to move the server worker into net.c branch:michael preparing to move the server worker into net.c Dec 11, 2009 r222 (branch:michael fixed missing headers files....) committed by michael@hinespot.net - branch:michael fixed missing headers files.... branch:michael fixed missing headers files.... Dec 11, 2009 r221 (branch:michael fixed missing headers files....) committed by michael@hinespot.net - branch:michael fixed missing headers files.... branch:michael fixed missing headers files.... Dec 11, 2009 r220 (branch:michael improved memx transfer support.) committed by michael@hinespot.net - branch:michael improved memx transfer support. branch:michael improved memx transfer support. Dec 10, 2009 r219 (branch:michael bug fixes. cleanups.) committed by michael@hinespot.net - branch:michael bug fixes. cleanups. branch:michael bug fixes. cleanups. Dec 10, 2009 r218 (branch:michael preparing to remove a header....) committed by michael@hinespot.net - branch:michael preparing to remove a header.... branch:michael preparing to remove a header.... Dec 09, 2009 r217 (branch:michael lots of code cleanup that was long overdue) committed by michael@hinespot.net - branch:michael lots of code cleanup that was long overdue branch:michael lots of code cleanup that was long overdue Dec 09, 2009 r216 (branch:michael lots of code cleanup that was long overdue) committed by michael@hinespot.net - branch:michael lots of code cleanup that was long overdue branch:michael lots of code cleanup that was long overdue Dec 09, 2009 r215 (branch:michael lots of code cleanup that was long overdue) committed by michael@hinespot.net - branch:michael lots of code cleanup that was long overdue branch:michael lots of code cleanup that was long overdue Dec 09, 2009 r214 (branch:michael lots of code cleanup that was long overdue) committed by michael@hinespot.net - branch:michael lots of code cleanup that was long overdue branch:michael lots of code cleanup that was long overdue Dec 09, 2009 r213 (branch:michael this commit completely removes any dependency...) committed by michael@hinespot.net - branch:michael this commit completely removes any dependency on ethernet-specific code from memx. All transmissions and receives are done strictly on top of the net_device structure which theoretically is completely layer-2 agnostic. branch:michael this commit completely removes any dependency on ethernet-specific code from memx. All transmissions and receives are done strictly on top of the net_device structure which theoretically is completely layer-2 agnostic. Dec 09, 2009 issue 5 (Softlockup while running intense workload on /dev/amema) commented on by michael@hinespot.net - Let's move this to the mailing list...... Let's move this to the mailing list...... Dec 08, 2009 issue 5 (Softlockup while running intense workload on /dev/amema) commented on by bluehwak - Thanks guys for your quick response. R U planning to add support for IPOIB in memx. ? Is there any tweaks you guys can suggest to improve memx performance. ( I am using memx block device as swap device) I want to try to make it run on IPOIB. I believe it will help memx to transfer pages so fast to remote machine memory. But am new to these kind of kernel level coding. Can you suggest some place where I can start digging or some kind of documentation on your code which will help me to do this. I am happy to help you guys if you are planning to add support for IPOIB in memx. Thanks again for your help. :) Thanks guys for your quick response. R U planning to add support for IPOIB in memx. ? Is there any tweaks you guys can suggest to improve memx performance. ( I am using memx block device as swap device) I want to try to make it run on IPOIB. I believe it will help memx to transfer pages so fast to remote machine memory. But am new to these kind of kernel level coding. Can you suggest some place where I can start digging or some kind of documentation on your code which will help me to do this. I am happy to help you guys if you are planning to add support for IPOIB in memx. Thanks again for your help. :) Dec 07, 2009 r212 (branch:michael usage change errors) committed by michael@hinespot.net - branch:michael usage change errors branch:michael usage change errors Dec 07, 2009 r211 (branch:michael additional documentation) committed by michael@hinespot.net - branch:michael additional documentation branch:michael additional documentation Dec 07, 2009 Usage Wiki page edited by michael@hinespot.net - Revision r210 Edited wiki page through web user interface. Revision r210 Edited wiki page through web user interface. Dec 07, 2009 issue 8 (network code should auto-detect default ethernet interface) changed by michael@hinespot.net - This is completed now. In branch:michael Status: Fixed Owner: mich...@hinespot.net This is completed now. In branch:michael Status: Fixed Owner: mich...@hinespot.net Dec 07, 2009 issue 5 (Softlockup while running intense workload on /dev/amema) commented on by michael@hinespot.net - ACK. The MAC length as well as the long frame length (4 kilobytes). From the output it looks like memx is incorrectly detecting the number of fragments required to send an infiniband message. We're unfamiliar with how Linux represents a "struct net_device" for infiniband, so there's not much we can do without actually getting in there and mucking around by hand to see the net_device structure inside the kernel..... ACK. The MAC length as well as the long frame length (4 kilobytes). From the output it looks like memx is incorrectly detecting the number of fragments required to send an infiniband message. We're unfamiliar with how Linux represents a "struct net_device" for infiniband, so there's not much we can do without actually getting in there and mucking around by hand to see the net_device structure inside the kernel..... Dec 07, 2009 issue 5 (Softlockup while running intense workload on /dev/amema) commented on by kartik.gopalan - Actually MemX totally bypasses the IP layer, so configuring IPOIB will not make MemX work. We need to account for the longer IB mac address in the code, which may take some time (unless you can fix it before we do :) Actually MemX totally bypasses the IP layer, so configuring IPOIB will not make MemX work. We need to account for the longer IB mac address in the code, which may take some time (unless you can fix it before we do :) Dec 06, 2009 issue 5 (Softlockup while running intense workload on /dev/amema) commented on by bluehwak - Hi, Had tried as u mentioned. Please find the logs below. msubsys: net_check_nic_status:325 gather unavailable - enabling workaround. msubsys: NIC: ib0, MTU: 2044, frags/page: 9 @ 00:00:04:04:fe:80 Memx info on Client returns empty server list. I doubt the IPOIB interface MAC id is truncated in ipconfig and arp tables I had checked the MAC address on one machine using cat /sys/class/net/ib0/address which is 00:00:04:04:fe:80:00:00:00:00:00:00:00:19:bb:xx:xx:xx:xx:ad (I had replaced actual characters with x) But reflects in ifconfig and arp as follows ifconfig output: ib0 Link encap:UNSPEC HWaddr 00-00-04-04-FE-80-00-00-00-00-00-00-00-00-00-00 ARP table: 192.168.x.x ether 00:00:04:04:FE:80:00 C ib0 192.168.x.x ether 00:00:04:04:FE:80:00 C ib0 Does memx have any dependency on these informations ???. Waiting for your reply . Thanks in advance :) Hi, Had tried as u mentioned. Please find the logs below. msubsys: net_check_nic_status:325 gather unavailable - enabling workaround. msubsys: NIC: ib0, MTU: 2044, frags/page: 9 @ 00:00:04:04:fe:80 Memx info on Client returns empty server list. I doubt the IPOIB interface MAC id is truncated in ipconfig and arp tables I had checked the MAC address on one machine using cat /sys/class/net/ib0/address which is 00:00:04:04:fe:80:00:00:00:00:00:00:00:19:bb:xx:xx:xx:xx:ad (I had replaced actual characters with x) But reflects in ifconfig and arp as follows ifconfig output: ib0 Link encap:UNSPEC HWaddr 00-00-04-04-FE-80-00-00-00-00-00-00-00-00-00-00 ARP table: 192.168.x.x ether 00:00:04:04:FE:80:00 C ib0 192.168.x.x ether 00:00:04:04:FE:80:00 C ib0 Does memx have any dependency on these informations ???. Waiting for your reply . Thanks in advance :) Dec 05, 2009 r209 (branch:michael print changes) committed by michael@hinespot.net - branch:michael print changes branch:michael print changes Dec 05, 2009 r208 (branch:michael bugfix, was allocating memory with GFP_KERNEL...) committed by michael@hinespot.net - branch:michael bugfix, was allocating memory with GFP_KERNEL in atomic context. That's a boo-boo. branch:michael bugfix, was allocating memory with GFP_KERNEL in atomic context. That's a boo-boo. Dec 05, 2009 r207 (branch:michael removed module parameters forever! only ioctl...) committed by michael@hinespot.net - branch:michael removed module parameters forever! only ioctl() now. branch:michael removed module parameters forever! only ioctl() now. Dec 03, 2009 r206 (branch:michael significantly more user-friendly memx now.) committed by michael@hinespot.net - branch:michael significantly more user-friendly memx now. branch:michael significantly more user-friendly memx now. Dec 03, 2009 r205 (branch:michael significantly more user-friendly memx now.) committed by michael@hinespot.net - branch:michael significantly more user-friendly memx now. branch:michael significantly more user-friendly memx now. Dec 03, 2009 issue 5 (Softlockup while running intense workload on /dev/amema) commented on by michael@hinespot.net - That's great. To answer your other question: we don't have any infiniband hardware, so we've never been able to iron out what might cause that problem when setting nic=ib0. Try setting "debug=3" to memx and see if there are any broadcast messages printed out. MemX uses broadcasts to discover server existence... That's great. To answer your other question: we don't have any infiniband hardware, so we've never been able to iron out what might cause that problem when setting nic=ib0. Try setting "debug=3" to memx and see if there are any broadcast messages printed out. MemX uses broadcasts to discover server existence... Dec 02, 2009 issue 5 (Softlockup while running intense workload on /dev/amema) commented on by bluehwak - Hi mhinespot, Thanks for your response & Srry for the late reply . I was out of station. I am able to figure out why my Memx client machine is crashing. This was because of the bnx NIC driver problem (Problem still exists with latest driver also) . I had added new NIC card of different manufacture and wroking fine . Memx Rocks... :) . Thanks for this wonderful product. I have one more query is it possible to run memx on IPOIB (using nic=ib0). I had tried but could not able to see memory servers and getting error on starting block. Expecting your valuable inputs. FYI (bnx bug) : http://kerneltrap.org/mailarchive/linux-netdev/2008/6/16/2140074 Hi mhinespot, Thanks for your response & Srry for the late reply . I was out of station. I am able to figure out why my Memx client machine is crashing. This was because of the bnx NIC driver problem (Problem still exists with latest driver also) . I had added new NIC card of different manufacture and wroking fine . Memx Rocks... :) . Thanks for this wonderful product. I have one more query is it possible to run memx on IPOIB (using nic=ib0). I had tried but could not able to see memory servers and getting error on starting block. Expecting your valuable inputs. FYI (bnx bug) : http://kerneltrap.org/mailarchive/linux-netdev/2008/6/16/2140074 Dec 02, 2009 r204 (branch:michael - added more ioctls to support built-in kerne...) committed by michael@hinespot.net - branch:michael - added more ioctls to support built-in kernel compilation branch:michael - added more ioctls to support built-in kernel compilation Dec 02, 2009 r203 (help target in the makefile) committed by michael@hinespot.net - help target in the makefile help target in the makefile

issue 5 (Softlockup while running intense workload on /dev/amema) commented on by bluehwak - Hi, Had tried as u mentioned. Please find the logs below. msubsys: net_check_nic_status:325 gather unavailable - enabling workaround. msubsys: NIC: ib0, MTU: 2044, frags/page: 9 @ 00:00:04:04:fe:80 Memx info on Client returns empty server list. I doubt the IPOIB interface MAC id is truncated in ipconfig and arp tables I had checked the MAC address on one machine using cat /sys/class/net/ib0/address which is 00:00:04:04:fe:80:00:00:00:00:00:00:00:19:bb:xx:xx:xx:xx:ad (I had replaced actual characters with x) But reflects in ifconfig and arp as follows ifconfig output: ib0 Link encap:UNSPEC HWaddr 00-00-04-04-FE-80-00-00-00-00-00-00-00-00-00-00 ARP table: 192.168.x.x ether 00:00:04:04:FE:80:00 C ib0 192.168.x.x ether 00:00:04:04:FE:80:00 C ib0 Does memx have any dependency on these informations ???. Waiting for your reply . Thanks in advance :)

Hi, Had tried as u mentioned. Please find the logs below. msubsys: net_check_nic_status:325 gather unavailable - enabling workaround. msubsys: NIC: ib0, MTU: 2044, frags/page: 9 @ 00:00:04:04:fe:80 Memx info on Client returns empty server list. I doubt the IPOIB interface MAC id is truncated in ipconfig and arp tables I had checked the MAC address on one machine using cat /sys/class/net/ib0/address which is 00:00:04:04:fe:80:00:00:00:00:00:00:00:19:bb:xx:xx:xx:xx:ad (I had replaced actual characters with x) But reflects in ifconfig and arp as follows ifconfig output: ib0 Link encap:UNSPEC HWaddr 00-00-04-04-FE-80-00-00-00-00-00-00-00-00-00-00 ARP table: 192.168.x.x ether 00:00:04:04:FE:80:00 C ib0 192.168.x.x ether 00:00:04:04:FE:80:00 C ib0 Does memx have any dependency on these informations ???. Waiting for your reply . Thanks in advance :)

Last 7 days

Last 30 days