From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755886Ab2CIWGn (ORCPT ); Fri, 9 Mar 2012 17:06:43 -0500 Received: from mail-iy0-f174.google.com ([209.85.210.174]:40733 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753042Ab2CIWGl (ORCPT ); Fri, 9 Mar 2012 17:06:41 -0500 Date: Fri, 9 Mar 2012 14:06:23 -0800 From: Mandeep Singh Baines To: Tejun Heo Cc: Mandeep Singh Baines , Andrew Morton , Mikulas Patocka , linux-kernel@vger.kernel.org, dm-devel@redhat.com, Alasdair G Kergon , Will Drewry , Elly Jones , Milan Broz , Olof Johansson , Steffen Klassert , Rusty Russell Subject: Re: workqueues and percpu (was: [PATCH] dm: remake of the verity target) Message-ID: <20120309220623.GM27051@google.com> References: <1330648393-20692-1-git-send-email-msb@chromium.org> <20120306215947.GB27051@google.com> <20120308143909.bfc4cb4d.akpm@linux-foundation.org> <20120308231521.GA2968@htj.dyndns.org> <20120309211512.GL27051@google.com> <20120309212049.GD24890@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120309212049.GD24890@google.com> X-Operating-System: Linux/2.6.38.8-gg683 (x86_64) User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tejun Heo (tj@kernel.org) wrote: > Hello, > > On Fri, Mar 09, 2012 at 01:15:12PM -0800, Mandeep Singh Baines wrote: > > In this case, I need the per-cpu data for the duration of calculating > > a cryptographics hash on a 4K page of data. That's a long time to disable > > pre-emption. > > How long are we talking about? Tens of microsecs, tens of millisecs? > It depends on the H/W. We are running on Atom w/ PREEMPT_DESKTOP so we aren't pre-emptible even now. But I think there is interest from other folks in embedded to use the work. So it potentially be millisecs on a slower few hundred MHZ embedded processor. > > I could fix the bug temporarily by adding get/put for the per_cpu data > > but would that be acceptable? I'm not sure what the OK limit is for how > > long one can disable preemption. An alternative fix would be not allow > > CONFIG_VERITY when CONFIG_HOTPLUG_CPU. Once workqueues are fixed, I could > > remove that restriction. > > I think the right thing to do for now is to add cpu hotplug notifier > and do flush_work_sync() on the work item. We can later move that > logic into workqueue and remove it from crypto. > That seems like the correct solution. I will implement that. Thanks, Mandeep > Thanks. > > -- > tejun