Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758194Ab0GBJeb (ORCPT ); Fri, 2 Jul 2010 05:34:31 -0400 Received: from mail-bw0-f46.google.com ([209.85.214.46]:46679 "EHLO mail-bw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755326Ab0GBJe3 (ORCPT ); Fri, 2 Jul 2010 05:34:29 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uJ8RvBD8LUtNs7zwsdqiTy6XGGELjXf3kOUb7Wef6SVghhoLI6O+AVy6bzRbMGVER2 /AEpU2V0idsCIvqvNxBq5VDf/94EbPIY7duhfBEPZ16mqNZbnkH9XykZAF5gOaMuHEP3 kE1je1YBMc1ForTtbhMRbPC3+PBpGRWIk5dpk= MIME-Version: 1.0 In-Reply-To: References: <20100702085323.GF10072@secunet.com> <20100702091726.GH10072@secunet.com> Date: Fri, 2 Jul 2010 13:34:27 +0400 Message-ID: Subject: Re: [PATCH 1/3] padata: separate serial and parallel cpumasks From: Dan Kruchinin To: Steffen Klassert Cc: LKML , Herbert Xu Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2117 Lines: 59 On Fri, Jul 2, 2010 at 1:32 PM, Dan Kruchinin wrote: > On Fri, Jul 2, 2010 at 1:17 PM, Steffen Klassert > wrote: >> On Fri, Jul 02, 2010 at 01:07:44PM +0400, Dan Kruchinin wrote: >>> > >>> ... >> >> But the active cpumask, and now also your serial cpumask might change. >> We need to catch this changes somehow, that's why I checked the active >> cpumask against the callback cpu. > > You're right, now I get it. Hence the right solution is to check if > callback CPU is set in serial cpumask every time we do > padata_do_serial and if it's not, recalculate its value. padata_do_parallel of course. > The only thing that embarrasses me in this scheme is the fact that we > have to allocate cpumask_var_t in pcrypt_do_parallel every time we > call it then copy serial cpumask into allocated one and then check the > cb_cpu. > I think it would be better if we somehow could avoid dynamic cpumask > allocation. I see the following solutions: > > 1) Do the check and cb_cpu value recalculation in padata_do_parallel. > It may check if cb_cpu is in serial_cpumask and recalculate its value > if it isn't. The drawback of this scheme is that padata_do_parallel > now doesn't guaranty it will forward serialization job to the same > callback CPU we passed to it. If passed CPU is not in serial cpumask > it will forward serialization to another CPU and we won't know its > number. The only thing we'll know is that this CPU is in the > serial_cpumask. > 2) Create new structure describing pcrypt instance in pcrypt.c which > will include waitqueue, padata instance and preallocated cpumask which > will be used for getting padata instance serial cpumsak. It'll help to > avoid dynamic cpumask allocation but it looks a bit awkward. > >> >> Steffen >> >> > > > > -- > W.B.R. > Dan Kruchinin > -- W.B.R. Dan Kruchinin -- 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/