From owner-freebsd-current@FreeBSD.ORG Wed Mar 19 17:08:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 774C772; Wed, 19 Mar 2014 17:08:59 +0000 (UTC) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC359164; Wed, 19 Mar 2014 17:08:58 +0000 (UTC) Received: by mail-yh0-f53.google.com with SMTP id v1so8851380yhn.40 for ; Wed, 19 Mar 2014 10:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4FiEl4kB7n7tEzJgl+xLsnrar0/TRAtwv/q/kQnRAH4=; b=SHCm9xYgQxpNFO8hAQW3YZTocayHlz1yCsfV0nDaeixLuxlDG9oMCDJL0xxFhv3vXC ghMZZf0wcvn/jehTbteDBB0fhv0eFP2khI+QALefwO3m9Naf1XOSlR0vGLdL3WSmiYWM 23x4f1/iQ4k+WLsav4fXqX088zRsct+lugOPsX137nHI1NeyPax4XISMWpHYSr/aAUiv m8XNd69szBlHlEXGkH37VdBIrGg+I9a8QVgtH19oaOKDyjpw+ms25ExXVpiauPbskGah tywZZd3pRWdFddi/SlDbnRWrhBEjnPyssllIzjmHHoZ0ulbmMk7wbRBLNlgtuM58Nr8t IUVw== MIME-Version: 1.0 X-Received: by 10.236.50.194 with SMTP id z42mr3700999yhb.145.1395248938174; Wed, 19 Mar 2014 10:08:58 -0700 (PDT) Received: by 10.170.66.204 with HTTP; Wed, 19 Mar 2014 10:08:58 -0700 (PDT) In-Reply-To: References: <20140314070218.GA37327@FreeBSD.org> <201403181426.19929.jhb@freebsd.org> Date: Wed, 19 Mar 2014 13:08:58 -0400 Message-ID: Subject: Re: FreeBSD GSOC proposal in 2014 From: yan cui To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, "Wojciech A. Koszek" , soc-status@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 17:08:59 -0000 Any comments for this thread? There is only three days left for application. If the proposed idea should not be considered in this year, it should be removed from the GSoC idea list and I will submit a different proposal about the CPU hot plug problem in the FreeBSD kernel. Thanks, Yan 2014-03-18 15:39 GMT-04:00 yan cui : > Really? Maybe I can download his code from previous GSoC. > Actually, before applying for this idea, I did not scan the projects in > previous years and just pick up one which I like. > Are there any possibilities to improve on this part (or this idea should > not be considered any more)? > > Yan > > > 2014-03-18 14:26 GMT-04:00 John Baldwin : > > On Friday, March 14, 2014 3:02:18 am Wojciech A. Koszek wrote: >> > On Thu, Mar 13, 2014 at 09:56:35PM -0400, yan cui wrote: >> > > Hi all, >> > > >> > > I write this mail to make my question clear. I know witness can be >> used >> > > to detect wrong lock order in the kernel. However, can it be used to >> do >> > > lock profiling (what I mean is to report the information such as which >> > > locks are most contended and print some related statistics such as >> calling >> > > graph, etc)? >> > > In other words, is it enough to finish the task by porting witness to >> the >> > > pthread library? >> > > >> > >> > Yan, >> > >> > To my knowledge WITNESS is the only tool for lock order verification. >> > >> > For lock profiling in the FreeBSD kernel there's a KTR subsystem. KTR >> > mechanism is basically like syslog() in the user-space, but for the >> kernel. >> > KTR subsystem will receive messages from KTR API that is placed in the >> > FreeBSD kernel. Messages get stored on the list of some sort. List can >> be >> > exported to a file. File you can later analyze. >> > >> > Jeff wrote a Python app which can be used for pre-processing the KTR >> logs >> > from scheduler and protting them visually. Link: >> > >> > http://svnweb.freebsd.org/base/head/tools/sched/schedgraph.py >> > >> > Instead of porting witness to pthreads, maybe we could evaluate >> expanding >> > WITNESS to cover kern_umtx? This could prove to be more universal. >> > >> > Wojciech >> >> There is a dedicated lock profiler (LOCK_PROFILING) in the kernel. A >> previous GSoC student from an earlier year has already re-implemented both >> LOCK_PROFILING and WITNESS for pthreads. >> >> -- >> John Baldwin >> > > > > -- > Think big; Dream impossible; Make it happen. > -- Think big; Dream impossible; Make it happen.