From owner-svn-src-user@FreeBSD.ORG Fri Oct 26 06:27:04 2012 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14A6363D; Fri, 26 Oct 2012 06:27:04 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id A3E428FC14; Fri, 26 Oct 2012 06:27:02 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so1909689lbd.13 for ; Thu, 25 Oct 2012 23:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9p2xxVdiyj6WL5sw8jBKRC9wIgWNIyUepGSGecGhl2A=; b=VbtuG4SCpy01qQtuQRTAa1p24rlTen09iUXDYkbpZucI9TovG315WmaKOg2y5ZpL32 2nZjk0AKgSCI5kZmYIcYIdHAlGdlbaZMVQySNM4qpTLLOGnbLXcD3Nrwy8H5c4udsb21 goLaaSEDQrEtuneUE2HheA7iSRsmeiTyRZ6J7PUMWNzUZhESg/bQjOeuZflLEexSvn+W UoKDk9aZvqCEgHgoF7okE+az2Ux4cs4uEH17eEhNdYO4GWYpccW/UTUBIssYJR/GRKkF kntY9HJI7Swh0Co3eBLC8PN0VBVyHIJXxrdYSgU9x5o+6dGVRi4R9n5IpYXBF2ovt2dY pcpg== MIME-Version: 1.0 Received: by 10.152.105.103 with SMTP id gl7mr19403783lab.10.1351232821024; Thu, 25 Oct 2012 23:27:01 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Thu, 25 Oct 2012 23:27:00 -0700 (PDT) In-Reply-To: <5089A913.2040603@freebsd.org> References: <201210221418.q9MEINkr026751@svn.freebsd.org> <201210241136.06154.jhb@freebsd.org> <201210241414.30723.jhb@freebsd.org> <508965B3.2020705@freebsd.org> <5089A913.2040603@freebsd.org> Date: Fri, 26 Oct 2012 07:27:00 +0100 X-Google-Sender-Auth: QVe95cdu3LGtZkiP4rGkO_oy9dk Message-ID: Subject: Re: svn commit: r241889 - in user/andre/tcp_workqueue/sys: arm/arm cddl/compat/opensolaris/kern cddl/contrib/opensolaris/uts/common/dtrace cddl/contrib/opensolaris/uts/common/fs/zfs ddb dev/acpica dev/... From: Attilio Rao To: Andre Oppermann Content-Type: text/plain; charset=UTF-8 Cc: mdf@freebsd.org, src-committers@freebsd.org, John Baldwin , svn-src-user@freebsd.org, Jeff Roberson , Bruce Evans X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 06:27:04 -0000 On Thu, Oct 25, 2012 at 10:03 PM, Andre Oppermann wrote: > On 25.10.2012 18:21, Attilio Rao wrote: >> >> On Thu, Oct 25, 2012 at 5:15 PM, Andre Oppermann >> wrote: >>> >>> On 25.10.2012 05:14, Attilio Rao wrote: >>>> >>>> >>>> On Wed, Oct 24, 2012 at 9:13 PM, Attilio Rao >>>> wrote: >>>> I think I've had a better idea for this. >>>> In our locking scheme we already rely on the fact that lock_object >>>> will always be present in all our locking primitives and that it will >>>> be the first object of every locking primitives. This is an assumption >>>> we must live with in order to correctly implement lock classes. I >>>> think we can use the same concept in order to use the same KPI for the >>>> 2 different structures (struct mtx and struct mtx_unshare) and keep >>>> the compile time ability to find stupid bugs. >>> >>> >>> >>> I think we're completely overdoing it. On amd64 the size difference >>> of 64B cache line aligning and padding all mutex, sx and rw_lock >>> structures adds the tiny amount of 16K on a GENERIC kernel of 19MB. >>> That is a 0.009% increase in size. Of course dynamically allocated >>> memory that includes a mutex grows a tiny bit at well. >>> >>> Hence I propose to unconditionally slap __aligned(CACHE_LINE_SIZE) into >>> all locking structures and be done with it. As an added benefit we >>> don't have to worry about individual micro-optimizations on a case by >>> case basis. >> >> >> Did you see my (and also Jeff) objection to your proposal about this? >> You are deliberating ignoring this? > > > Well, I'm allowed to have a different opinion, am I? I'm not ignoring > your objection in the sense as I'm not trying to commit any of this to > HEAD while it is disputed. > > Mind you this whole conversation was started because I was trying to solve > a problem with unfortunate cache line sharing for global mutexes in the > kernel .bss section on my *personal* svn branch. Andre, I'm sorry if you felt I was being harsh or confrontative. This was really not my intention and I apologize. Said that, I fail in seeing a proper technical discussion on your side on how what I propose is "overdoing it" or how do you plan to address the concerns people are raising with your proposal of bumping all lock sizes indiscriminately. However, here is the first half of the patch I'd like to see in: http:///www.freebsd.org/~attilio/mtx_decoupled.patch This is just the part to give the ability to crunch different structures to the mtx KPI. Please note that from the users perspective the mtx KPI remains absolutely the same, so there is theoretically no KPI discontinuity, the support is absolutely transparent. It is not yet throughfully tested, because I first want to hear opinions also on nits. For example: - Do we need to implement mtxlock2mtx() only in kern_mutex.c? I'd say yes, as a general rule, but as long as this functionality relies on the ABI maybe it is better to leave it in _mutex.h as done in the patch. - MTX_SYSINIT() doesn't work for hypotetical mtx_unshare right now so it will need to have its own version. Should I add it now? Should I add it if and only if there is a real need? (I suspect this is likely because several external mutexes, that we want to convert, may use it) - others that came to your mind Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein