lkml.org 
[lkml]   [1999]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: spin_unlock optimization
Date
On Thu, 30 Dec 1999 22:21:03 +0000, 
Steve Dodd <dirk@loth.demon.co.uk> wrote:
>On Thu, Dec 30, 1999 at 04:06:04AM +0100, Oliver Henning wrote:
>> well, not necessarily. If you would modify the spin_unlock asm sequence at
>> boot time, there would be no performance loss. But self-modifying code is
>> not very desirable, so...
>
>Erm, spin_unlock is inlined isn't it? So that won't work unless you want to
>grep for the code sequence all over the kernel and modules; also, the binary
>module people would be forced to brutally murder you :-)

It is technically possible to automate this, using the same trick as
copy_from_user. spin_unlock generates worst case code and stores the
start and end of the code in yet another ELF section. Kernel boot code
decides which version to use, runs the data in the new ELF section and
patches the code before starting the second processor. insmod does the
same thing. Cost is extra storage in zImage and modules, the extra
section would be discarded after loading so it does not bloat the
running kernel. Binary modules (yuck) compiled with the old
spin_unlock would not have the optimized code but they would still
work.

Whether this is a desirable thing to do is another question ;).


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.103 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site