From owner-svn-src-head@freebsd.org Thu Jan 7 15:37:10 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0168AA668A2; Thu, 7 Jan 2016 15:37:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 762851D50; Thu, 7 Jan 2016 15:37:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u07Fb3kn062625 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 17:37:03 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u07Fb3kn062625 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u07Fb380062624; Thu, 7 Jan 2016 17:37:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 7 Jan 2016 17:37:03 +0200 From: Konstantin Belousov To: Chagin Dmitry Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r275121 - in head/sys: compat/linux compat/svr4 fs/procfs kern sys Message-ID: <20160107153703.GV3625@kib.kiev.ua> References: <201411261410.sAQEA0JO071065@svn.freebsd.org> <20160107133953.GA62554@chd.heemeyer.club> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160107133953.GA62554@chd.heemeyer.club> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 15:37:10 -0000 On Thu, Jan 07, 2016 at 04:39:53PM +0300, Chagin Dmitry wrote: > On Wed, Nov 26, 2014 at 02:10:00PM +0000, Konstantin Belousov wrote: > > Author: kib > > Date: Wed Nov 26 14:10:00 2014 > > New Revision: 275121 > > URL: https://svnweb.freebsd.org/changeset/base/275121 > > > > Log: > > The process spin lock currently has the following distinct uses: > > > > - Threads lifetime cycle, in particular, counting of the threads in > > the process, and interlocking with process mutex and thread lock. > > The main reason of this is that turnstile locks are after thread > > locks, so you e.g. cannot unlock blockable mutex (think process > > mutex) while owning thread lock. > > > > - Virtual and profiling itimers, since the timers activation is done > > from the clock interrupt context. Replace the p_slock by p_itimmtx > > and PROC_ITIMLOCK(). > > > > - Profiling code (profil(2)), for similar reason. Replace the p_slock > > by p_profmtx and PROC_PROFLOCK(). > > > > - Resource usage accounting. Need for the spinlock there is subtle, > > my understanding is that spinlock blocks context switching for the > > current thread, which prevents td_runtime and similar fields from > > changing (updates are done at the mi_switch()). Replace the p_slock > > by p_statmtx and PROC_STATLOCK(). > > > > The split is done mostly for code clarity, and should not affect > > scalability. > > > > Tested by: pho > > Sponsored by: The FreeBSD Foundation > > MFC after: 1 week > hi, any chance to merge it? I do not want to merge the split, for many reasons. I suppose the merge conflicts due to the replace of PROC_SLOCK() by PROC_*LOCK() are what you are looking after, am I right ? What could be done, is to merge the syntax changes from the patch. I mean, provide the PROC_*LOCK() macros and merge all changes to use new macros, but internal implementation would still lock the same proc spinlock.