lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date:	Thu, 13 Mar 2008 15:07:25 -0300
From:	"Carlos R. Mafra" <crmafra2@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Swap scheduling?

I just want to provide some latencytop numbers which I
collected during the experience described in another thread
( http://lkml.org/lkml/2008/3/13/134 ).

The behaviour is not completely reproducible. I've just repeated
the test of opening the 380MB file with xjed and it turned out
ok, just like I dream it to be. 

This is what I had before opening the file a few moments ago:
(Window Maker + firefox + thunderbird + mrxvt + xterm)

[mafra@...alhost:~]$ free
             total       used       free     shared    buffers     cached
Mem:        513872     403316     110556          0      49076     214084
-/+ buffers/cache:     140156     373716
Swap:      2144636          0    2144636

Then I tryed to open the 380MB file, which took like 30 seconds but
meanwhile I could switch desktops, type in the terminal and I could have
closed the xjed window if I wanted (ie the mouse was responsive and I
could "aim" it very well)

So far so good! I was also running latencytop and this is what I got
in a random moment (I don't know if latencytop has a record of the
worst latencies. Arjan?):

Cause                                                Maximum     Percentage
sync_page __lock_page handle_mm_fault do_page_faul442.7 msec         36.0 %
Scheduler: waiting for cpu                        365.8 msec         54.5 %
sync_buffer __wait_on_buffer __bread ext3_get_bran335.5 msec          2.3 %
sync_buffer __wait_on_buffer ext3_find_entry ext3_252.5 msec          0.3 %
sync_page __lock_page find_lock_page filemap_fault235.3 msec          4.4 %
sync_page __lock_page handle_mm_fault do_page_faul208.4 msec          0.3 %
sync_page __lock_page handle_mm_fault do_page_faul104.7 msec          0.1 %
sync_page wait_on_page_bit shmem_getpage shmem_fau 99.0 msec          0.2 %
sync_page __lock_page handle_mm_fault do_page_faul 72.9 msec          0.1 %
o_read do_sync_read vfs_read sys_read



Process wmaker (3406)
sync_page __lock_page handle_mm_fault do_page_faul442.7 msec         32.0 %
sync_page __lock_page find_lock_page filemap_fault188.0 msec         20.1 %lt do_page_fault error_code
Scheduler: waiting for cpu                         77.0 msec         47.6 %
do_select core_sys_select sys_select sysenter_past  2.1 msec          0.2 %


However, I also happen to have another latencytop log which I could
gather while the desktop was misbehaving a few days ago during
this same test. It looks like this:

Cause                                                Maximum     Percentage
get_request_wait __make_request generic_make_reque1423.6 msec          9.4 %
get_request_wait __make_request generic_make_reque1328.4 msec          5.7 %
sync_page __lock_page handle_mm_fault do_page_faul902.1 msec          0.5 %
sync_page __lock_page find_lock_page filemap_fault885.0 msec         23.8 %
sync_page __lock_page handle_mm_fault do_page_faul831.1 msec         32.2 %
sync_page __lock_page handle_mm_fault do_page_faul588.8 msec          0.3 %
get_request_wait __make_request generic_make_reque565.2 msec          0.3 %
get_request_wait __make_request generic_make_reque549.5 msec          0.3 %
sync_buffer __wait_on_buffer __bread ext3_get_bran423.0 msec          2.1 %
dahead do_page_cache_readahead filemap_fault


Process wmaker (3518)                                                                                                                                          
get_request_wait __make_request generic_make_reque1377.7 msec         25.5 %ge shrink_page_list shrink_inactive_list shrink_zone try_to_free_pages __alloc_page
sync_page __lock_page handle_mm_fault do_page_faul570.5 msec         19.3 %
sync_buffer __wait_on_buffer __bread ext3_get_bran349.4 msec          8.6 % ext3_get_block do_mpage_readpage mpage_readpages ext3_readpages __do_page_cache_rea
Scheduler: waiting for cpuhead filemap_fault      242.3 msec         39.5 %
get_request_wait __make_request generic_make_reque149.2 msec          2.8 %age shrink_page_list shrink_inactive_list shrink_zone try_to_free_pages __alloc_page
sync_page __lock_page find_lock_page filemap_fault127.3 msec          3.4 %lt do_page_fault error_code

I could take this from latencytop while xjed was almost finishing
to load the file. I see some ~1 second figures there, but I must
say that it was taking much longer (like 10 seconds) to get any
reaction to a typed letter in the terminal. It was difficult to
aim the mouse pointer etc (because it disapeared for seconds).

Well, these are some numbers. People who know things better 
can judge them better than me! :-)
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ