Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756482Ab0GBLUP (ORCPT ); Fri, 2 Jul 2010 07:20:15 -0400 Received: from a.mx.secunet.com ([195.81.216.161]:45259 "EHLO a.mx.secunet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753172Ab0GBLUM (ORCPT ); Fri, 2 Jul 2010 07:20:12 -0400 Date: Fri, 2 Jul 2010 13:21:41 +0200 From: Steffen Klassert To: Dan Kruchinin Cc: LKML , Herbert Xu Subject: Re: [PATCH 2/2] pcrypt: sysfs interface Message-ID: <20100702112141.GJ10072@secunet.com> References: <20100629203939.29a0b4ff@leibniz> <20100630124742.GD10072@secunet.com> <20100702090801.GG10072@secunet.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-06-14) X-OriginalArrivalTime: 02 Jul 2010 11:20:02.0769 (UTC) FILETIME=[83F4F410:01CB19D8] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 979 Lines: 23 On Fri, Jul 02, 2010 at 02:20:15PM +0400, Dan Kruchinin wrote: > > > > Yes, I thought about something like this. You can still take the sum > > over the percpu objects when you output the statistics. > > But summation can not be clear without some kind of lock because > while we're summing another CPU can increase or decrease its percpu statistic > counters. Then each statistic percpu counter must be modified under lock, right? > Yes, the counters must accessed under lock. In the fastpath functions you hold the appropriate lock anyway. Modifying a local percpu value should not be too painfull there. The expensive thing is to access the percpu statistics, but this happens on demand and is probaply a rare event. Steffen -- 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/