#10112 NORM Not Tri: GUI freezes on fsync
Zarro Boogs per Child
bugtracker at laptop.org
Mon Apr 12 21:14:42 EDT 2010
#10112: GUI freezes on fsync
---------------------------+------------------------------------------------
Reporter: jon.nettleton | Owner:
Type: defect | Status: new
Priority: normal | Milestone: Not Triaged
Component: not assigned | Version: Development build as of this date
Keywords: | Next_action: never set
Verified: 0 | Deployment_affected:
Blockedby: | Blocking:
---------------------------+------------------------------------------------
Using firefox from the GNOME desktop you find that there are frequent GUI
freezes, no clicking, no screen refresh etc. After running
{{{
strace -p $(pgrep firefox) -e fsync,fdatasync -tT
}}}
it became obvious that we are suffering from long fsync writes to the
filesystem. I then installed the same OS v119 to a high speed external
SDHC card and moved the olpc home directory over to it. This should give
the exact same firefox sqlite databases and information. I found the
fsync's to be virtually un-noticable. Here are the two datasets, I tried
to mimic the testing to be the same in each instance.
{{{
Internal SD Card:
17:51:28 fdatasync(62) = 0 <3.099224>
17:51:31 fdatasync(62) = 0 <0.450451>
17:51:32 fdatasync(31) = 0 <0.519231>
17:51:35 fsync(57) = 0 <3.760307>
17:51:50 fsync(83) = 0 <5.421490>
17:52:05 fsync(54) = 0 <0.460336>
17:52:16 fsync(70) = 0 <2.439097>
17:52:18 fdatasync(62) = 0 <0.036100>
17:52:19 fdatasync(62) = 0 <0.006095>
17:52:19 fdatasync(31) = 0 <0.872539>
17:52:29 fsync(54) = 0 <3.460910>
17:52:42 fsync(54) = 0 <0.440038>
17:53:19 fsync(77) = 0 <0.461735>
17:53:22 fsync(81) = 0 <3.364934>
17:53:35 fsync(63) = 0 <3.332061>
17:53:49 fsync(55) = 0 <0.018636>
17:54:00 fsync(53) = 0 <0.014304>
18:01:37 fsync(18) = 0 <1.332728>
18:01:48 fsync(63) = 0 <0.856377>
}}}
{{{
External SDHC
17:46:54 fsync(46) = 0 <0.020497>
17:47:15 fsync(62) = 0 <0.176407>
17:47:19 fdatasync(60) = 0 <0.332567>
17:47:19 fdatasync(60) = 0 <0.163582>
17:47:20 fdatasync(24) = 0 <0.270497>
17:47:25 fsync(57) = 0 <0.166996>
17:47:32 --- SIGCHLD (Child exited) @ 0 (0) ---
17:47:34 fdatasync(60) = 0 <1.356135>
17:47:35 fdatasync(60) = 0 <0.004512>
17:47:35 fdatasync(24) = 0 <0.209471>
17:47:39 fsync(82) = 0 <0.288864>
17:47:50 fsync(83) = 0 <0.180585>
17:47:53 --- SIGCHLD (Child exited) @ 0 (0) ---
17:47:53 --- SIGCHLD (Child exited) @ 0 (0) ---
17:47:53 --- SIGCHLD (Child exited) @ 0 (0) ---
17:47:55 fdatasync(60) = 0 <0.014631>
17:47:56 fdatasync(60) = 0 <0.002435>
17:47:56 fdatasync(24) = 0 <0.137674>
17:48:00 fsync(83) = 0 <0.442724>
17:48:11 fsync(67) = 0 <0.308368>
17:48:11 fdatasync(60) = 0 <0.176889>
17:48:11 fdatasync(60) = 0 <0.002327>
17:48:11 fdatasync(24) = 0 <0.311335>
17:48:12 --- SIGCHLD (Child exited) @ 0 (0) ---
17:48:13 --- SIGCHLD (Child exited) @ 0 (0) ---
17:48:21 fsync(68) = 0 <0.178435>
17:48:31 fsync(37) = 0 <0.170102>
}}}
Obviously there are two big differences 1 the speed difference, but
secondly the SIGCHLD's. I am not sure what caused them but I am
disregarding them temporarily.
My external SDHC card is a class 6 card. I decided to check performance
as I don't know what the internal card is. Running hdparm -Tt ( I know it
is a horrible benchmark, but I haven't gotten that far into this problem
yet ) I actually found the buffered and unbuffered read speeds to be quite
similar. This doesn't help with the write speed benchmarking needed for
fsync's but it showed there wasn't a horribly obvious performance
difference between the cards.
I will update this bug with more information after write speeds are
tested.
--
Ticket URL: <http://dev.laptop.org/ticket/10112>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs
mailing list