[lkml]   [2011]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc
On Nov 10, 2011, at 23:40, Benjamin Herrenschmidt wrote:
> On Thu, 2011-11-10 at 18:38 -0600, Moffett, Kyle D wrote:
>> (2) Make the ppc64_caches struct apply to ppc32 as well, and
>> preinitialize it with a minimum value used by any platform being
>> compiled in (for "dcbXX"/"icbXX" purposes). This is safe because
>> the pagesize is always a multiple of the cache block size and the
>> kernel only uses dcbXX/icbXX on whole pages. The only impact is a
>> temporary small performance hit from flushing or zeroing the same
>> block 8 times if too small.
> Are you sure about dcbz ? Getting that wrong can be deadly ... I'd
> rather get rid of some fancy optims and use a soft value in some cases.
> That or we can compile multiple variants for the common case of some of
> the copy routines and use patching (alternate sections) to branch to the
> right one at runtime, at least for the common cases (32 and 128 for
> example for 440 and 476).

Well, all of the kernel loops that use dcbz are operating on whole pages,
and the PPC Book-E spec documents that the pagesize is an even multiple
of the cacheline size and the cachelines are always page-aligned.

So when you are clearing a whole page, there are only 2 things you can do
wrong with "dcbz":

(1) Call "dcbz" with an address outside of the page you want to zero.

(2) Omit calls "dcbz" to dcbz for some physical cachelines in the page.

Now, that's a totally different story from the userspace memset() calls
that caused the problem originally, because they were frequently given
memory much smaller than a page to clear, and if you didn't know exactly
how many bytes a "dcbz" was going to clear you couldn't use it at all.

But the kernel doesn't do that anywhere, it just uses it for page clears.

Kyle Moffett

Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here:

 \ /
  Last update: 2011-11-15 03:57    [W:0.065 / U:7.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site