Nick Piggin wrote:
Benjamin Herrenschmidt wrote:
On Mon, 2007-07-09 at 19:29 +1000, Nick Piggin wrote:
They could just #define one to the other though, there are only a
small
number of them. Is there a downside to not making them distinct? i386
for example probably would just keep doing a tlb flush for fork and
not
want to worry about touching the tlb gather stuff.
But the tlb gather stuff just does ... a flush_tlb_mm() on x86 :-)
But it still does the get_cpu of the mmu gather data structure and
To elaborate on this one... I realise for this one that in the kernel
where this is currently used everything is non-preemptible anyway
because of the ptl. And I also realise that -rt kernel issues don't
really have a bearing on mainline kernel.. but the generic
implementation of this API is fundamentally used to operate on a
per-cpu data structure that is only required when tearing down page
tables. That makes this necessarily non-preemptible.
Which shows that it adds more restrictions that may not otherwise be
required.
has to look in there and touch the cacheline. You're also having to
do more work when unlocking/relocking the ptl etc.
I really think it's the right API
OK, the *form* of the API is fine, I have no arguments. I just don't
know why you have to reuse the same thing. If you provided a new set of
names then you can trivially do a generic implementation which compiles
to exactly the same code for all architectures right now. That seems to
me like the right way to go...
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
