From mboxrd@z Thu Jan 1 00:00:00 1970 From: jim owens Subject: Re: [RFC][PATCH] kmap_atomic_push Date: Fri, 09 Oct 2009 08:15:42 -0400 Message-ID: <4ACF296E.3000000@hp.com> References: <1255016123.17055.17.camel@laptop> <20091008155344.GA11727@elte.hu> <1255019362.26976.311.camel@twins> <4ACE674E.30403@hp.com> <1255042636.17055.33.camel@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1255042636.17055.33.camel@laptop> Sender: linux-kernel-owner@vger.kernel.org To: Peter Zijlstra Cc: Hugh Dickins , Linus Torvalds , Ingo Molnar , Avi Kivity , Andrew Morton , David Howells , lkml , linux-arch List-Id: linux-arch.vger.kernel.org Peter Zijlstra wrote: > > The double unmap gives a preemption point, which sounds like a good > thing to have, because your scheme could run for a long while without > enabling preemption, which is badness. Thanks, optimizing my loop, I forgot all about the old long code path not preempting problem. Now I have to love the patch for making it harder to be stupid :) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g4t0015.houston.hp.com ([15.201.24.18]:28923 "EHLO g4t0015.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760623AbZJIMRO (ORCPT ); Fri, 9 Oct 2009 08:17:14 -0400 Message-ID: <4ACF296E.3000000@hp.com> Date: Fri, 09 Oct 2009 08:15:42 -0400 From: jim owens MIME-Version: 1.0 Subject: Re: [RFC][PATCH] kmap_atomic_push References: <1255016123.17055.17.camel@laptop> <20091008155344.GA11727@elte.hu> <1255019362.26976.311.camel@twins> <4ACE674E.30403@hp.com> <1255042636.17055.33.camel@laptop> In-Reply-To: <1255042636.17055.33.camel@laptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Peter Zijlstra Cc: Hugh Dickins , Linus Torvalds , Ingo Molnar , Avi Kivity , Andrew Morton , David Howells , lkml , linux-arch Message-ID: <20091009121542.6ua5mYJZDy-j2TAk1QtRaMnhHAfzN8IpPp_PBO0MPIs@z> Peter Zijlstra wrote: > > The double unmap gives a preemption point, which sounds like a good > thing to have, because your scheme could run for a long while without > enabling preemption, which is badness. Thanks, optimizing my loop, I forgot all about the old long code path not preempting problem. Now I have to love the patch for making it harder to be stupid :)