lkml.org 
[lkml]   [2012]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 01/22] ARM: add mechanism for late code patching
On 8/6/2012 9:26 AM, Russell King - ARM Linux wrote:
> On Mon, Aug 06, 2012 at 09:19:10AM -0400, Cyril Chemparathy wrote:
>> With a flush_cache_all(), we could avoid having to operate a cacheline
>> at a time, but that clobbers way more than necessary.
>
> You can't do that, because flush_cache_all() on some CPUs requires the
> proper MMU mappings to be in place, and you can't get those mappings
> in place because you don't have the V:P offsets fixed up in the kernel.
> Welcome to the chicken and egg problem.
>
>> Sure, flushing caches is expensive. But then, so is running the
>> patching code with caches disabled. I guess memory access latencies
>> drive the performance trade off here.
>
> There we disagree on a few orders of magnitude. There are relatively
> few places that need updating. According to the kernel I have here:
>
> text data bss dec hex filename
> 7644346 454320 212984 8311650 7ed362 vmlinux
>
> Idx Name Size VMA LMA File off Algn
> 1 .text 004cd170 c00081c0 c00081c0 000081c0 2**5
> 16 .init.pv_table 00000300 c0753a24 c0753a24 00753a24 2**0
>
> That's about 7MB of text, and only 192 points in that code which need
> patching. Even if we did this with caches on, that's still 192 places,
> and only 192 places we'd need to flush a cache line.
>
> Alternatively, with your approach and 7MB of text, you need to flush
> 238885 cache lines to cover the entire kernel.
>
> It would be far _cheaper_ with your approach to flush the individual
> cache lines as you go.
>

Agreed. Thanks.

--
Thanks
- Cyril


\
 
 \ /
  Last update: 2012-08-06 16:21    [W:0.077 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site