Very Computer

oops, it now seems that the swapped out pppd is still functioning.

Perhaps it is crapping out at some packet count level?

---rob---

Am I crazy or is pppd seizing up when it gets swapped out?

I'm having to re-establish the connection frequently.

Is there a way to flag processes not to be swapped?

(I'm running Linux on a 486/33 with 20 M RAM and 50? VM

If anyone has any ideas that could help me with this, I would
greatly appreciate hearing from you.  Thanks.

---rob---

"Dr. Rob Higgins" <rhiggins> writes:

Quote:>oops, it now seems that the swapped out pppd is still functioning.
>Perhaps it is crapping out at some packet count level?

I work in many systems environments which supported the concept of
locking pages during a read/write operation. This is needed if you are
going to access the memory during the interrupt cycle.

For some time, I thought that Linux needed this facility as well. It
came from a pre-conceived notion of "the way that things were to be
done".

It occurred to me that this is not needed for Linux.

The logic used for the tty read complete and the subsequent pppd read
is as follows:

procedure to handle the tty read completion at the interrupt:
begin
    if we can move all of the tty data to the holding buffer then
    begin
        indicate that the holding buffer has some data
        wake up the process sleeping on the read event
        return
    end

    since the buffer wont hold the data then print a message that the
    input frame is to be deleted and just ignore the input frame.
    return
end

procedure to read from the daemon:
    validate the daemon's access to the user buffer pointer as given

    while data is not present in the holding buffer do
    begin
        sleep
        if we received a signal which must be reported then
            return the error that we were interrupted
    end

    do some setup processing for the new read
    move the data from the holding buffer to the user buffer
    indicate that the holding buffer is empty
    return the count read
end

Now, if you look at the logic and consider that the kernel will do the
page replacement only while it is in the middle of the system call,
then there is no need to 'lock' the pages down. As the move is
performed, should the buffer not be present in memory, the page should
be brought in from the swap device.

The kernel will panic if the page is not present and you are in the
middle of an interrupt processing state.

No access is made to the user buffer while handling the interrupt.

The write is essentially the same only in reverse:

procedure to write from the daemon:
    validate the daemon's access to the buffer pointer as given

    while cant lock the write buffer because someone else is using it do
    begin
        sleep
        if we received a signal which must be reported then
            return the error that we were interrupted
    end

    do some setup processing for the new write
    move the data from the daemon buffer to the holding buffer
    start the tty driver doing the write operation
    return the count written
end

(the 'holding' buffers for read and write are separate)

When the write operation completes, the tty write complete will unlock
the buffer and wake up the process which is sleeping on the write
lock.

In short, there should not be a problem with the page replacement
provided that there is suitable physical memory to handle the page
entry. By that I mean that the kernel must find a page to be replaced
by the needed entry for the pppd buffer. It may result in writing a
page out to the swap file.

The exact implementation details are in the ppp.c driver.

p.s.: If you compile the pppd daemon with the linker flag "-N", then
you will generate a non-swappable executable. The system will preload
the entire program before it starts to run it and not swap any of it
out to memory. If you are short of memory then doing this then it will
make your small problem very much larger as pppd is not a small
program.

--