Subject: [linux-audio-dev] [PATCH--] Re: [DATAPOINT] latency report (overrepresented instructions)
From: Roger Larsson (roger.larsson_AT_norran.net)
Date: Thu Jul 27 2000 - 19:53:02 EEST
Hi,
Have retested with Andrew Mortons most recent release.
Still got hit by those shrink_mmaps...
But since we now hit swap less than before I moved the
count decrement before the test of referenced.
(Like this, line # with Andrews patch applied)
@@ -261,14 +262,13 @@ int shrink_mmap(int priority, int gfp_ma
/* we need pagemap_lru_lock for list_del() ... subtle code below
*/
spin_lock(&pagemap_lru_lock);
- while (count > 0 && (page_lru = lru_cache.prev) != &lru_cache) {
+ while (--count >= 0 && (page_lru = lru_cache.prev) !=
&lru_cache) {
page = list_entry(page_lru, struct page, lru);
list_del(page_lru);
if (PageTestandClearReferenced(page))
goto dispose_continue;
- count--;
This got rid of the problems in shrink_mmap.
Performance got slightly worse...
I investigate further.
/RogerL
Roger Larsson wrote:
>
> Hi,
>
> The most interesting part first.
> With or without Andrew Mortons lowlatency patch
> this exact sample shows up often(in 10 - 25 ms hits):
> [shrink_mmap+66/504]
>
> Since my latency profiling patch samples IP at jiffies
> I would have expected more diverted locations but for
> some reason it almost always samples at that point...
> Is this due to cache misses?
> [Included disassembly of shrink_mmap for reference]
>
> ========================
> Kernel 2.4.0-test5-pre4:
>
> shrink_mmap is hit nine times all at [shrink_mmap+66/504]
>
> When rewriting a file i hit a latency of > 60 ms
> (can slab poisoning be a cause?)
>
> [try_to_free_buffers][block_flushpage][__remove_from_lru_list]
> [truncate_inode_pages][__free_pages_ok]
>
> and on another occasion
>
> [unmap_buffer][kmem_cache_free][__free_pages_ok]
>
> At first streaming copy a 36 ms hit.
> [block_flushpage][truncate_inode_pages]
>
> When running a dbench 16
> shrink_mmap reports again at same location
> and finally a try_to_free_buffers
>
> Running mmap002 gives LOTS of reports with a maximum of 151 ms
> [set_bh_page+1/64] [block_getblk+34/824] [wake_up_process+6/216]
> [block_getblk+150/824] [do_buffer_fdatasync+26/124]
> [do_buffer_fdatasync+26/124] [writeout_one_page+27/80]
> [writeout_one_page+27/80] [do_buffer_fdatasync+26/124]
> [generic_make_request+1706/1744][writeout_one_page+11/80]
> [ll_rw_block+223/376] [generic_make_request+1706/1744]
> [ll_rw_block+104/376] [generic_make_request+1706/1744]
> I included the addresses in this. You see that some gets sampled
> at same location all the time; generic_make_request is one
> but ll_rw_block gets different locations. But I got very
> few samples of these => no statistical relevance.
>
> ===================
> With Andrew Mortons lowlatency patch things look better.
> [reapplied from test3, not the latest...]
>
> Only hurt by occasional shrink_mmap:
> [shrink_mmap+66/504] nine times and
> two times at [shrink_mmap+85/504]
>
> and swapper doing something for 31 ms that did not get
> sampled???
>
> Trying a dbench16 again [shrink_mmap+66/504] and at different
> occasions (< 11 ms):
> [ide_dmaproc]
> [try_to_free_buffers]
> [__remove_from_lru_list]
>
> Running the "Don't do that" mmap002 the maximum latency
> is 23 ms !
> --
> Home page:
> http://www.norran.net/nra02596/
>
> ------------------------------------------------------------------------
> Name: shrink_mmap.asm.gz
> shrink_mmap.asm.gz Type: application/x-gzip
> Encoding: base64
-- Home page: http://www.norran.net/nra02596/
This archive was generated by hypermail 2b28 : Thu Jul 27 2000 - 21:18:56 EEST