[OpenAFS-devel] Very simple patch for libafs CPU hog on signal
Nickolai Zeldovich
kolya@MIT.EDU
Mon, 28 Jan 2002 19:21:12 -0500
> > 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.
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.
> 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.)
-- kolya