Re: ITP memlockd
On Friday 09 February 2007 22:47, [EMAIL PROTECTED] wrote: > Where can I get the code ? :-) http://www.coker.com.au/memlockd/ I've now made a second release of memlockd, it's at the above URL. -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
Re: ITP memlockd
On Friday 09 February 2007 22:47, [EMAIL PROTECTED] wrote: > superb, I've wanted one of these for a long time :-) > > Other scenarios might include having a working system if the binary > images are not acccessible for some other reason such as h/w failure ?? If the kernel umounts a filesystem because of IO errors then you can't execute the program without a directory entry. However if you have a running program and memlockd had kept it in ram then it should keep running after a drive fails (unless of course it's data pages had been swapped out). To keep a program running after a failure the mlockall() system call might be the best option. > I had thought that the sticky bit had once been used like this? > but I went away and read just now that it was a bit different. The sticky bit was apparently aimed for better performance during regular operation. Shared objects and aggressive disk caching made it less useful so it was never implemented in Linux. > How does it interact with the filesystem? I imagine that if I rm > /bin/bash then I can no longer simply execute it in the usual way, > even if the pages are still locked in memory (and do you unlock > the pages when the underlying file is removed ?) My program won't notice a file removal unless you kill -1 it. > Is there any guarantee that the various directories and inodes needed > (are they needed??) will be in memory ? No. > Where can I get the code ? :-) As it's only 1K compressed I've attached an early version of the source (consider it version 0). -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development memlockd.cpp.gz Description: GNU Zip compressed data
Re: ITP memlockd
On Fri, Feb 09, 2007 at 08:57:19AM +1100, Russell Coker wrote: > memlockd - daemon to lock files into RAM > > When a system starts paging excessively it may be impossible for the sysadmin > to login for the purpose of killing the runaway processes (sometimes the > login program times out due to thrashing). Memlockd allows important system > files (such as /bin/login, /bin/getty, and the admin shell) to be locked in > memory so that there will be no delay in accessing executable pages. In my > tests this can decrease the time required for the administrator to login on a > thrashing system by a factor of more than 3. > > GPL, I wrote it. superb, I've wanted one of these for a long time :-) Other scenarios might include having a working system if the binary images are not acccessible for some other reason such as h/w failure ?? I had thought that the sticky bit had once been used like this? but I went away and read just now that it was a bit different. I take it you handle package installs ? How does it interact with the filesystem? I imagine that if I rm /bin/bash then I can no longer simply execute it in the usual way, even if the pages are still locked in memory (and do you unlock the pages when the underlying file is removed ?) Is there any guarantee that the various directories and inodes needed (are they needed??) will be in memory ? I have too many questions ... Where can I get the code ? :-) Regards, Paddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP memlockd
On Friday 09 February 2007 10:43, Brian May <[EMAIL PROTECTED]> wrote: > How much memory typically needs to be locked for this to be > beneficial? It's best to have the shell used by the sysadmin, the login chain (getty + login or sshd and the PAM stuff), some utilities (EG busybox), and all shared objects used by them. But you can get by with a lot less. I've attached a sample config file that causes just under 10M of RAM to be used. No big deal on a machine with 256M of RAM that is likely to experience a DOS attack. -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development /bin/bash /lib/libncurses.so.5 /lib/tls/i686/cmov/libdl.so.2 /lib/tls/i686/cmov/libc.so.6 /usr/sbin/sshd /lib/libwrap.so.0 /lib/libpam.so.0 /lib/tls/i686/cmov/libdl.so.2 /lib/libselinux.so.1 /lib/tls/i686/cmov/libresolv.so.2 /usr/lib/i686/cmov/libcrypto.so.0.9.8 /lib/tls/i686/cmov/libutil.so.1 /usr/lib/libz.so.1 /lib/tls/i686/cmov/libnsl.so.1 /lib/tls/i686/cmov/libcrypt.so.1 /usr/lib/libgssapi_krb5.so.2 /usr/lib/libkrb5.so.3 /usr/lib/libk5crypto.so.3 /lib/libcom_err.so.2 /usr/lib/libkrb5support.so.0 /lib/tls/i686/cmov/libc.so.6 /lib/ld-linux.so.2 /lib/libsepol.so.1 /bin/busybox /lib/tls/i686/cmov/libm.so.6
Re: ITP memlockd
> "Russell" == Russell Coker <[EMAIL PROTECTED]> writes: Russell> memlockd - daemon to lock files into RAM When a system Can I assume there is meant to be a full stop after RAM? It reads very differently otherwise... Russell> starts paging excessively it may be impossible for the Russell> sysadmin to login for the purpose of killing the runaway Russell> processes (sometimes the login program times out due to Russell> thrashing). Memlockd allows important system files (such Russell> as /bin/login, /bin/getty, and the admin shell) to be Russell> locked in memory so that there will be no delay in Russell> accessing executable pages. In my tests this can Russell> decrease the time required for the administrator to login Russell> on a thrashing system by a factor of more than 3. How much memory typically needs to be locked for this to be beneficial? (I guess this would depend on what PAM and NSS modules you use...) -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
