> My problem with that approach is that the args struct is simply dead
> memory until the actual call happens. That has kept me from setting up
> everything (including the RPC task) at the moment the request is created.
> OTOH it would be critical for swapping over NFS not to block in those
> operations... sigh.
>
> The writeback code in its current form is pretty awkward anyway. The
> way I implemented it you can't do any advanced stuff such as page
> coalescing or even NFSv3 etc. I've completely rewritten it for NFSv3.
OK, I'll try experimenting with incorporating the wb_args and fattr into
the req. The structures are only 84 bytes total, so even if the
writeback list was full this would add only a couple of pages. It seems
better to let the writes proceed unblocked than to incur an extra
potential delay at that point.
> > Also, it appears that after canceling a write request the request isn't
> > awakened, and so a truncated page might sit for quite a while on the
> > writeback list before being released. I think it would be better for
> > rpc_exit to awaken the task after setting the action to null, so that
> > everything would get cleaned up sooner. Does this sound reasonable to
> > you?
>
> I'm not sure. I dimly remember there was a reason why I didn't want
> rpc_exit to wake up the task, but I don't recall what the problem was.
> If in doubt, just try and see what happens.
I checked the usage of rpc_exit and it appears to be called most
frequently from a context where a wake_up isn't needed. So I've just
added an rpc_wake_up in the nfs writeback code when a request gets
cancelled.
Regards,
Bill