On Fri, 1 Oct 2010 19:09:41 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Thu, Sep 23, 2010 at 10:46:47AM -0400, J. Bruce Fields wrote: > > On Wed, Sep 22, 2010 at 11:25:40PM -0400, J. Bruce Fields wrote: > > > On Thu, Sep 23, 2010 at 01:00:02PM +1000, Neil Brown wrote: > > > > How about this. > > > > It gets rid of the return values (which were confusing anyway) and adds > > > > explicit checks on CAHCE_PENDING where needed. > > > > ?? > > > > > > Thanks, I'll take a look in the morning when my head's (hopefully) > > > clearer. > > > > Looks reasonable to me on a quick skim. > > > > > > Also, I noticed there is a race with the call to cache_limit_defers. The > > > > 'dreq' could be freed before that is called. > > > > > > > > It looks like I need to resubmit a lot of this - do you want to just discard > > > > it all from your -next and I'll make something new? > > > > > > I'm trying very hard not to rewind -next; so I'd prefer incremental > > > patches for anything already there, replacements for the rest. > > > > But I'll wait for a new series. Thanks! > > Well, just to have the bug fixed, I've applied your simple original fix > (1/7), but would still happily take incremental cleanup. Thanks. I've been on leave this past week, but have now flagged this email for attention when I get back into things next week. > > Out of this series that just leaves > > [PATCH 4/7] sunrpc/cache: centralise handling of size limit on > deferred list. > > [PATCH 5/7] sunrpc/cache: allow thread manager more control of > whether threads can wait for upcalls > > (And with no particular objection to either--they just seemed more RFC's > than "please apply"'s.) .... Yes..... I think I like them, but until I have some idea of what if anything could/should be done to the usage of request deferral in lockd, it is hard know whether it is really worth the churn. So let's leave them for now. Thanks, NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
