Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758239AbaLJW4m (ORCPT ); Wed, 10 Dec 2014 17:56:42 -0500 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:58054 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751399AbaLJW4l (ORCPT ); Wed, 10 Dec 2014 17:56:41 -0500 Date: Wed, 10 Dec 2014 14:56:29 -0800 From: Shaohua Li To: Andy Lutomirski CC: "linux-kernel@vger.kernel.org" , X86 ML , , "H. Peter Anvin" , Ingo Molnar Subject: Re: [PATCH 3/3] X86: Add a thread cpu time implementation to vDSO Message-ID: <20141210225627.GA11754@devbig257.prn2.facebook.com> References: <862cbb2ab71a9f71d1123b5512605350a4b61846.1418006970.git.shli@fb.com> <20141210215713.GA30230@devbig257.prn2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-Originating-IP: [192.168.57.29] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2014-12-10_09:2014-12-10,2014-12-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=21.7374254348843 compositescore=0.923639739835017 urlsuspect_oldscore=0.923639739835017 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=62764 rbsscore=0.923639739835017 spamscore=0 recipient_to_sender_domain_totalscore=35 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412100217 X-FB-Internal: deliver Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 10, 2014 at 02:13:23PM -0800, Andy Lutomirski wrote: > On Wed, Dec 10, 2014 at 1:57 PM, Shaohua Li wrote: > > On Wed, Dec 10, 2014 at 11:10:52AM -0800, Andy Lutomirski wrote: > >> On Sun, Dec 7, 2014 at 7:03 PM, Shaohua Li wrote: > >> > This primarily speeds up clock_gettime(CLOCK_THREAD_CPUTIME_ID, ..). We > >> > use the following method to compute the thread cpu time: > >> > >> I like the idea, and I like making this type of profiling fast. I > >> don't love the implementation because it's an information leak (maybe > >> we don't care) and it's ugly. > >> > >> The info leak could be fixed completely by having a per-process array > >> instead of a global array. That's currently tricky without wasting > >> memory, but it could be created on demand if we wanted to do that, > >> once my vvar .fault patches go in (assuming they do -- I need to ping > >> the linux-mm people). > > > > those info leak really doesn't matter. > > Why not? Ofcourse I can't make sure completely, but how could this info be used as attack? > > But we need the global array > > anyway. The context switch detection should be per-cpu data and should > > be able to access in remote cpus. > > Right, but the whole array could be per process instead of global. > > I'm not saying I'm sure that would be better, but I think it's worth > considering. right, it's possible to be per process. As you said, this will waster a lot of memory. and you can't even do on-demand, as the context switch path will write the count to the per-process/per-thread vvar. Or you can maintain the count in kernel and let the .fault copy the count to vvar page (if the vvar page is absent). But this still wastes memory if applications use the vdso. I'm wondering how you handle page fault in context switch too if you don't pin the vdso pages. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/