[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <200802181440.39159.nickpiggin@yahoo.com.au>
Date: Mon, 18 Feb 2008 14:40:38 +1100
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Török Edwin <edwintorok@...il.com>
Cc: Arjan van de Ven <arjan@...ux.intel.com>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: LatencyTOP: sync_page description
On Saturday 16 February 2008 08:56, Török Edwin wrote:
> Hi Arjan,
>
> LatencyTOP says that sync_page is 'Writing a page to disk', however
> I see that even when no writes are involved, such as during a
> readdir, lseek, etc.
> Naming it a write is misleading, as no program is running that is
> doing constant writes to the disk. The only program is writing to a
> temp dir in /dev/shm.
>
> What would be a better description for sync_page?
Waiting on a page state change (usually: waiting for IO, but can be
also waiting for the page lock which is taken by some other part of
the kernel eg in page reclaim, truncate, buffered writes, page
faults).
> Here are some /proc/latency_stats containing sync_page:
>
> 125 6937678 210821 sync_page sync_page_killable sync_page_killable
> __lock_page_killable wake_bit_function generic_file_aio_read
> get_unused_fd_flags path_walk do_sync_read autoremove_wake_function
> security_file_permission rw_verify_area
> 306 5677749 215746 sync_page sync_page_killable sync_page_killable
> __lock_page_killable wake_bit_function generic_file_aio_read
> do_sync_read autoremove_wake_function security_file_permission
> rw_verify_area vfs_read vfs_llseek
> 21 435657 59966 sync_page sync_page __lock_page wake_bit_function
> read_cache_page_async ntfs_readpage read_cache_page map_mft_record
> ntfs_read_locked_inode ntfs_alloc_big_inode iget5_locked
> ntfs_test_inode
> 195 2716409 133660 blk_unplug sync_page sync_page __lock_page
> wake_bit_function read_cache_page_async ntfs_readpage
> read_cache_page map_mft_record ntfs_read_locked_inode
> ntfs_alloc_big_inode iget5_locked
> 28 1881278 181986 add_to_page_cache_lru sync_page sync_page_killable
> sync_page_killable __lock_page_killable wake_bit_function
> generic_file_aio_read get_unused_fd_flags path_walk do_sync_read
> autoremove_wake_function security_file_permission
> 2 17132 9746 add_to_page_cache_lru sync_page sync_page_killable
> sync_page_killable __lock_page_killable wake_bit_function
> generic_file_aio_read do_sync_read autoremove_wake_function
> security_file_permission rw_verify_area vfs_read
> 1 70 70 irq_exit sync_page sync_page_killable sync_page_killable
> __lock_page_killable wake_bit_function generic_file_aio_read
> do_sync_read autoremove_wake_function security_file_permission
> rw_verify_area vfs_read
> 23 306682 114514 blk_unplug sync_page sync_page_killable
> sync_page_killable __lock_page_killable wake_bit_function
> generic_file_aio_read do_sync_read autoremove_wake_function
> security_file_permission rw_verify_area vfs_read
> 1 153 153 hrtimer_interrupt smp_apic_timer_interrupt sync_page
> sync_page_killable sync_page_killable __lock_page_killable
> wake_bit_function generic_file_aio_read do_sync_read
> autoremove_wake_function cfq_idle_slice_timer security_file_permission
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists