Message-ID: <497FA7DD.5000105@kernel.org>
Date: Wed, 28 Jan 2009 09:33:33 +0900
From: Tejun Heo <tj@kernel.org>
User-Agent: Thunderbird 2.0.0.19 (X11/20081227)
MIME-Version: 1.0
To: Cliff Wickman <cpw@sgi.com>
CC: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 07/10] x86: uv cleanup
References: <E1LRy9o-0005WD-7N@eag09.americas.sgi.com>
In-Reply-To: <E1LRy9o-0005WD-7N@eag09.americas.sgi.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1474
Lines: 35

Cliff Wickman wrote:
> I appreciate your consolidation and cleanup of the UV code, relative
> to 32 vs 64.
> 
> I have a question about the addition of the
>         WARN_ON(!in_atomic());
> in uv_flush_tlb_others().
> The patch is
> http://marc.info/?l=linux-kernel&m=123252788121855&w=2
> 
> I expect this function to always entered preemptable.  
> Could you explain a bit about your thought behind this WARN_ON?

The function needs to return modified cpumask.  Before the patch, this
was achieved by the caller disabling preemption and pass modifiable
per-cpu cpumask and allowing uv code to modify it in place.  After the
patch, to put uv code in uv proper (so that the generic code doesn't
have to allocate percpu cpumask for it), this is moved into the uv
function.  The caller disables preemtion and uses the returned cpumask
which might or might not be the same array it gave to the function and
the array is guaranteed to be valid until preemption is re-enabled.
The meachnism itself isn't different.  Only what's done where has
changed to make it more modular.  More specifically, when uv is not
needed, the generic code can simply omit the uv related part including
the percpu cpumask allocation.

Thanks.

-- 
tejun
--
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/