From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: linux-nfs-owner@vger.kernel.org Received: from relay.parallels.com ([195.214.232.42]:43177 "EHLO relay.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754894Ab2ENJAW (ORCPT ); Mon, 14 May 2012 05:00:22 -0400 Message-ID: <4FB0C9A1.6080406@parallels.com> Date: Mon, 14 May 2012 13:00:17 +0400 From: Stanislav Kinsbursky MIME-Version: 1.0 To: "bfields@fieldses.org" CC: "linux-nfs@vger.kernel.org" , Jeff Layton Subject: Re: [RFC] NFSd laundromat containerization References: <4FAD1934.8070908@parallels.com> <20120511135306.GA12795@fieldses.org> <4FAE2659.4090107@parallels.com> <20120512141653.GA19757@fieldses.org> In-Reply-To: <20120512141653.GA19757@fieldses.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Sender: linux-nfs-owner@vger.kernel.org List-ID: On 12.05.2012 18:16, bfields@fieldses.org wrote: > On Sat, May 12, 2012 at 12:59:05PM +0400, Stanislav Kinsbursky wrote: >> On 11.05.2012 17:53, bfields@fieldses.org wrote: >>> On Fri, May 11, 2012 at 05:50:44PM +0400, Stanislav Kinsbursky wrote: >>>> Hello. >>>> I'm currently looking on NFSd laundromat work, and it looks like >>>> have to be performed per networks namespace context. >>>> It's easy to make corresponding delayed work per network namespace >>>> and thus gain per-net data pointer in laundromat function. >>>> But here a problem appears: network namespace is required to skip >>>> clients from other network namespaces while iterating over global >>>> lists (client_lru and friends). >>>> I see two possible solutions: >>>> 1) Make these list per network namespace context. In this case >>>> network namespace will not be required - per-net data will be >>>> enough. >>>> 2) Put network namespace link on per-net data (this one is easier, but uglier). >>> >>> I'd rather there be as few shared data structures between network >>> namespaces as possible--I think that will simplify things. >>> >>> So, of those two choices, #1. >>> >> >> Guys, I would like to discuss few ideas about caches and lists containerization. >> Currently, it look to me, that these hash tables: >> >> reclaim_str, conf_id, conf_str, unconf_str, unconf_id, sessionid >> >> and these lists: >> >> client_lru, close_lru >> >> have to be per net, while hash tables >> >> file, ownerstr, lockowner_ino >> >> and >> >> del_recall_lru lists >> >> have not, because they are about file system access. > > Actually, ownerstr and lockowner_ino should also both be per-container. > > So it's only file and del_recall_lru that should be global. (And > del_recall_lru might work either way, actually.) > >> If I'd containerize it this way, then looks like nfs4_lock_state() >> and nfs4_unlock_state() functions will protect only >> non-containerized data, while containerized data have to protected >> by some per-net lock. > > Sounds about right. > Bruce, Jeff, I've implemented these per-net hashes and lists (file hash and del_recall_lru remains global). But now I'm confused with locking. For example, let's consider file hash and del_recall_lru lists. It looks like they are protected by recall_lock. But in nfsd_forget_delegations() this lock is not taken. Is it a bug? If yes and recall_lock is used for file hash protection, then why do we need to protect nfsd_process_n_delegations() by nfs4_un/lock_state() calls? Actually, the problem I'm trying to solve is to replace global client_lock by per-net one where possible. But I don't clearly understand, what it protects. Could you, guys, clarify the state locking to me. -- Best regards, Stanislav Kinsbursky