lkml.org 
[lkml]   [2004]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH][2.6] Completely out of line spinlocks / i386
On Fri, 13 Aug 2004, William Lee Irwin III wrote:
>> text data bss dec hex filename
>> mainline: 19973522 6607761 1878448 28459731 1b242d3 vmlinux
>> cool: 19839487 6585707 1878448 28303642 1afe11a vmlinux
>> C-func: 19923848 6582771 1878384 28385003 1b11eeb vmlinux
>> unlock: 19895498 6582746 1878384 28356628 1b0b014 vmlinux
>> unlock-irq: 19889858 6582721 1878384 28350963 1b099f3 vmlinux
>> read-unlock: 19883858 6582674 1878384 28344916 1b08254 vmlinux
>> irqrestore: 19855759 6582442 1878384 28316585 1b013a9 vmlinux
>> rdunlockirq: 19855255 6582369 1878384 28316008 1b01168 vmlinux
>> rdunlckrstr: 19855007 6582236 1878384 28315627 1b00feb vmlinux

On Fri, Aug 13, 2004 at 10:15:45AM -0400, Zwane Mwaikambo wrote:
> I was meaning to ask before, got ideas for lock profiling with this?

I don't have anything concrete, no. I suspect the same comments apply
generically to all architectures. One possible modification would be
for profile_tick() (in current -mm) to check for the text address being
in some ELF section dedicated to out-of-line locking functions and
unwind the stack one frame and account the tick to the caller.

The more problematic aspect of all this is that x86 is unique in its
code footprint for the unlock functions and IRQ masking being so small
as to merit inlining of these things. So the notion of a uniform API
that serves all architectures equally well is out the window.


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

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