[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1321400792.3170.17.camel@pasglop>
Date: Wed, 16 Nov 2011 10:46:32 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: "Moffett, Kyle D" <Kyle.D.Moffett@...ing.com>
Cc: "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"galak@...nel.crashing.org" <galak@...nel.crashing.org>,
"scottwood@...escale.com" <scottwood@...escale.com>,
"B04825@...escale.com" <B04825@...escale.com>,
"paul.gortmaker@...driver.com" <paul.gortmaker@...driver.com>,
Anton Blanchard <anton@....ibm.com>
Subject: Re: [RFC PATCH 0/2] powerpc: CPU cache op cleanup
On Tue, 2011-11-15 at 16:45 -0600, Moffett, Kyle D wrote:
> I guess that's doable, although I have to admit that idea almost gives
> me more of a headache than trying to fix up the 32-bit ASM.
>
> One thing that bothers me in particular is that both 32/64 versions of
> __copy_tofrom_user() are dramatically overcomplicated for what they
> ought to be doing.
>
> It would seem that if we get a page fault during an unaligned copy, we
> ought to just give up and fall back to a simple byte-by-byte copy loop
> from wherever we left off. That would eliminate 90% of the ugly
> special cases without actually hurting performance, right?
>
> For a page-fault during a cacheline-aligned copy, we should be able to
> handle the exception and retry from the last cacheline without much
> logic, again with good performance.
>
> With that said, I'm curious about the origin of the PPC32 ASM. In
> particular, it looks like it was generated by GCC at some point in the
> distant past, and I'm wondering if there's a good way to rewrite that
> file in C and trick GCC into generating the relevant exception tables
> for it?
There is some serious history in there :-)
I would check with Anton, he's been doing some performance work on those
lately (the 64-bit ones).
It's probably worth throwing a proof-of-concept simpler variant for
32-bit at least on the table and have people compare the perfs
(typically network perfs). I can test on a range of ppc32 here (6xx,
7xxx, 4xx).
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists