vetzki
Philosoph
- 1.750
- Themenstarter
- #121
hmm. ich hatte eigentlich ne zeitlang immer pa als standart rom genutzt und den jwr kernel. Kommt mir komisch vor da ich eigentlich keine probleme hatte, aber das mag nichts heißen. Kannst du evtl. falls möglich ist mit 1710 ein logcat & kmsg machen und hochladen bei den Hängern?. Viele kam seit 02.10 nicht dazu, aber vll. liegts daran (aber glaub ich eigentlich nicht)
Am Govenor dürfte es nicht liegen, aber am besten ondemand oder interactive benutzen, intellidemand braucht eigentlich kein mensch und eigentlich wars völlig unnötig ihn rein zu nehmen
Autor: Dave Chinner <dchinner@redhat.com> 2013-07-02 14:38:35
Eintragender: ... 2013-10-07 11:04:11
Eltern: 1e696cc61fd90f00c508e85be025590227de8c25 (kgsl: merge changes added on flo to make the alrgorithm a bit smarter.)
Kind: 848c2069ba0ff73fd3e8243046f61b6036b1ca35 (sound_control: just some cosmetic changes.)
Zweig: cm-10.2-jwr66-mv-oc
Folgt auf: v3.4
Vorgänger von:
sync: don't block the flusher thread waiting on IO
When sync does it's WB_SYNC_ALL writeback, it issues data Io and
then immediately waits for IO completion. This is done in the
context of the flusher thread, and hence completely ties up the
flusher thread for the backing device until all the dirty inodes
have been synced. On filesystems that are dirtying inodes constantly
and quickly, this means the flusher thread can be tied up for
minutes per sync call and hence badly affect system level write IO
performance as the page cache cannot be cleaned quickly.
We already have a wait loop for IO completion for sync(2), so cut
this out of the flusher thread and delegate it to wait_sb_inodes().
Hence we can do rapid IO submission, and then wait for it all to
complete.
Effect of sync on fsmark before the patch:
FSUse% Count Size Files/sec App Overhead
.....
0 640000 4096 35154.6 1026984
0 720000 4096 36740.3 1023844
0 800000 4096 36184.6 916599
0 880000 4096 1282.7 1054367
0 960000 4096 3951.3 918773
0 1040000 4096 40646.2 996448
0 1120000 4096 43610.1 895647
0 1200000 4096 40333.1 921048
And a single sync pass took:
real 0m52.407s
user 0m0.000s
sys 0m0.090s
After the patch, there is no impact on fsmark results, and each
individual sync(2) operation run concurrently with the same fsmark
workload takes roughly 7s:
real 0m6.930s
user 0m0.000s
sys 0m0.039s
IOWs, sync is 7-8x faster on a busy filesystem and does not have an
adverse impact on ongoing async data write operations.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Eintragender: ... 2013-10-07 11:04:11
Eltern: 1e696cc61fd90f00c508e85be025590227de8c25 (kgsl: merge changes added on flo to make the alrgorithm a bit smarter.)
Kind: 848c2069ba0ff73fd3e8243046f61b6036b1ca35 (sound_control: just some cosmetic changes.)
Zweig: cm-10.2-jwr66-mv-oc
Folgt auf: v3.4
Vorgänger von:
sync: don't block the flusher thread waiting on IO
When sync does it's WB_SYNC_ALL writeback, it issues data Io and
then immediately waits for IO completion. This is done in the
context of the flusher thread, and hence completely ties up the
flusher thread for the backing device until all the dirty inodes
have been synced. On filesystems that are dirtying inodes constantly
and quickly, this means the flusher thread can be tied up for
minutes per sync call and hence badly affect system level write IO
performance as the page cache cannot be cleaned quickly.
We already have a wait loop for IO completion for sync(2), so cut
this out of the flusher thread and delegate it to wait_sb_inodes().
Hence we can do rapid IO submission, and then wait for it all to
complete.
Effect of sync on fsmark before the patch:
FSUse% Count Size Files/sec App Overhead
.....
0 640000 4096 35154.6 1026984
0 720000 4096 36740.3 1023844
0 800000 4096 36184.6 916599
0 880000 4096 1282.7 1054367
0 960000 4096 3951.3 918773
0 1040000 4096 40646.2 996448
0 1120000 4096 43610.1 895647
0 1200000 4096 40333.1 921048
And a single sync pass took:
real 0m52.407s
user 0m0.000s
sys 0m0.090s
After the patch, there is no impact on fsmark results, and each
individual sync(2) operation run concurrently with the same fsmark
workload takes roughly 7s:
real 0m6.930s
user 0m0.000s
sys 0m0.039s
IOWs, sync is 7-8x faster on a busy filesystem and does not have an
adverse impact on ongoing async data write operations.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Am Govenor dürfte es nicht liegen, aber am besten ondemand oder interactive benutzen, intellidemand braucht eigentlich kein mensch und eigentlich wars völlig unnötig ihn rein zu nehmen
Zuletzt bearbeitet: