lkml.org 
[lkml]   [2003]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] 6/6 cacheline align files_lock
On Sat, Mar 08, 2003 at 07:41:42AM -0800, Martin J. Bligh wrote:
> Ironically, the latest scheduler changes *seem* to get rid of about
> 57% of the cost of it .... I have *no* idea why. Diffprofile between
> 64 and 64-bk is just wierd:
> 7222 45.1% page_remove_rmap
> 521 18.4% __copy_from_user_ll
> 422 8.9% __copy_to_user_ll
> 334 105.4% __wake_up
> 248 48.5% pte_alloc_one
> 243 205.9% pgd_ctor
> 211 4.6% vm_enough_memory
> 198 6.3% zap_pte_range
> 179 29.3% kmem_cache_free
> 118 12.2% clear_page_tables
> 99 13.2% __pte_chain_free
> 84 6.1% do_no_page
> 76 6.6% release_pages
> 74 9.0% strnlen_user
> 67 5.6% free_hot_cold_page
> 65 14.4% copy_page_range

The high count for pgd_ctor() is bizarre. It fiddles with less data and
should be called less often than pmd_ctor() or pte_alloc_one(), both of
which take the cache hit for constructing full pages, and pgd_ctor()
can't really hope to do better. This otherwise appears to be in order
of cacheline bounciness. DCU_MISS_OUTSTANDING and IFU_MEM_STALL?

page_remove_rmap() as usual takes top position b/c of its long list
walks; I think you've got something brewing for that already.


-- 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 13:33    [W:0.043 / U:1.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site