On Wed, Jun 25, 2008 at 2:50 PM, Martin Langhoff <[EMAIL PROTECTED]> wrote: > On Wed, Jun 25, 2008 at 2:36 PM, Bill Bogstad <[EMAIL PROTECTED]> wrote: >> I'm confused. Won't the XS servers always have swap/paging space? > > Paging is tolerable for batch processes, or for interactive stuff that > is not subject to timeouts (let the user wait while we bring > OpenOffice back from swap). Network services and swapping don't mix > well at all - they just timeout, which leads to users perceiving it as > "crashed", hitting "refresh" if available, and in our case perhaps > volunteering a "fix" in the form of a hard reboot.
Sure but any process that is waiting for a file to appear in the filesystem seem more like a batch process to me. There is no way to know how long it will take (and thus your timeouts). > > Ouch. > > If you look at apache and other web-services tuning strategies, the > *first* thing they do is ensure that the working set _never_ touches > swap. As soon as any network service gets swapped out, it's > unavailable for all intents and purposes. Yes, you want your working set to fit in memory. Still not clear to me how a process which is waiting (I'm assuming for a while) for another process to do something can in any sense be considered part of the current working set. In fact the usage model of incrond is that it won't even be a process (so clearly not in the working set). A paged out process is also clearly not in the current working set. Still not seeing the problem. OTOH, I do see the problem of using cron to startup a process just to check for existence of a file. Some other rendezvous is preferable. You don't seem to like DBUS (I'm guessing because of the complexity of retrofitting it into preexisting programs or scripts). Perhaps using a named pipe with a write to it from the source process to wake up the destination process might be preferable. This can easily be done from any language, doesn't require an additional permanent daemon process (incrond), and allows the destination process to have gotten past its startup cost and be ready for immediate action. Paging the destination process back from disk should not be slower then starting a new process (via incrond). The only advantage I see of incrond is the destination process can remain almost oblivious to the signaling mechanism. Named pipe rendezvous would require a small amount of additional code in both the source and destination process. > > Processes sitting idly in memory are wasteful unless they have a ton > of state in them to make them valuable. And even then, in many cases > they can just marshall that data, and pick it up later (lots of > exceptions for this - connection poolers for example). Processes that are truly 'idle' (waiting for a socket event for example) should be paged out as the system needs their memory. I can see lots of methods to avoid filesystem polling which don't involve adding a new daemon to the set of programs that OLPC is already supporting. Maybe the tradeoff is such that incrond is still the right choice, but I don't see why you seem to be objecting to a paged out process (as opposed to one which hasn't even been started yet). If the memory taken up by the process slot and other kernel bookkeeping is that much of a problem, then things are already so close to desperate that you are probably going to fall over soon anyway. Bill Bogstad _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
