[Server-devel] Yummy incron

[Bill Bogstad]

On Wed, Jun 25, 2008 at 2:50 PM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> On Wed, Jun 25, 2008 at 2:36 PM, Bill Bogstad <bogstad at pobox.com> 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