[OpenAFS-devel] Very simple patch for libafs CPU hog on signal

[Matt Peterson]

Kolya,

On Monday 28 January 2002 05:21 pm, Nickolai Zeldovich wrote:
> > >                                                        I think having
> > > the signal delivered when the AFS syscall completes would be a better
> > > solution.
> >
> > I agree that it would be good to allow the app in user space to handle
> > the syscall.  The problem is that there are several syscall that NEVER
> > return.
>
> Those places already mask out all signals (current->blocked), to my
> understanding.  This was just checked into CVS about a week ago, so
> perhaps you're running an older version that doesn't do this.  The
> remaining case where AFS would chew up CPU cycles is in `conventional'
> syscalls like read(), which will eventually return, and we can handle
> the signal then.

Hmmm.  I do need to be working off the latest stuff don't I.  I was not aware 
that fixes had been made in this area.  I'll get the latest.

> I think you might've missed my main point, though: in your patch,
> signals sent to the process while it's waiting in AFS are lost, which
> is probably a bad thing.

I know that there signals are lost with the patch.  The point I was trying to 
make (and I think we agree) is that it does not matter in cases where the 
syscall is not capable of return to caller anyway.

> > The work to make sure that these syscalls return gracefully with the
> > appropriate errorcodes is going to take some work.
>
> It might be relatively simple, though, to implement interruptability
> for common cases, such as waiting in rx_Read or rx_Write, or waiting
> for a background daemon to complete the request.  (Infact, the latter
> should be almost trivial.)

I whole-heartedly agree.  If there is interest in doing the work to 
streamline existing syscalls that really should return to caller (I'm 
interested) then the patch I propose would superceed these efforts as signals 
would be lost.   If there are not plans to streamline the code for signal 
processing then I'll stick with my patch that ignores them all -- its better 
than the CPU hog alternative...

Would some one in charge let me know if this (stream lining the VFS syscalls 
for signals) is a useful area of work?

Thanks,

-- 
Matt Peterson
Sr. Software Engineer
Caldera, Inc
matt@caldera.com