From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261381AbUBTXBM (ORCPT ); Fri, 20 Feb 2004 18:01:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261159AbUBTXBM (ORCPT ); Fri, 20 Feb 2004 18:01:12 -0500 Received: from dp.samba.org ([66.70.73.150]:28134 "EHLO lists.samba.org") by vger.kernel.org with ESMTP id S261381AbUBTXBJ (ORCPT ); Fri, 20 Feb 2004 18:01:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16438.37289.895975.757333@samba.org> Date: Sat, 21 Feb 2004 10:00:57 +1100 To: Linus Torvalds Cc: Ingo Molnar , Al Viro , Jamie Lokier , "H. Peter Anvin" , Kernel Mailing List Subject: Re: explicit dcache <-> user-space cache coherency, sys_mark_dir_clean(), O_CLEAN In-Reply-To: References: <16435.61622.732939.135127@samba.org> <20040219081027.GB4113@mail.shareable.org> <20040219163838.GC2308@mail.shareable.org> <20040219182948.GA3414@mail.shareable.org> <20040220120417.GA4010@elte.hu> <20040220170438.GA19722@elte.hu> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: tridge@samba.org From: tridge@samba.org Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Linus, > This is one of the reasons why I worry about user-space caching. It's just > damn hard to get right. yes, I'm concerned about that too. It does have the potential to be very fast though, as it allows us to index any way we want to (in the hot-cache paths at least). One thing that may be important to know is with the normal Samba process model there may be thousands of processes accessing this cache as Samba creates a new process for each connection. With futexes we have some chance of sanely managing access to a shared cache in user space between such a large pool of processes, so I don't think that is an insurmountable problem, but its something to consider when thinking of the normal use case of whatever solution is decided on. The current user-space positive name cache is per-process, largely because it was designed to be portable and nice things like futexes weren't available. At the time we also were trying to avoid too much OS specific stuff in Samba. We've got much better infrastructure for OS specific stuff now, so there is no problem with a Linux specific solution. The other unixes can just continue to be slow. Cheers, Tridge PS: Thanks _very_ much for all the effort on this!