Am 20.11.2011 06:20, schrieb Darren Steven: > I can explain this, as I see it too. Well, I can partially explain. > > It's caused by the kernel allocating large write buffers that can represent many minutes (or hours) of write time > for a slow USB device. You copy that file from a higher performing storage device, and you end up with many GB > buffered writes. KDE (or something in the UI render path) decides to stop while doing an fsync ( I'm not sure > exactly what), and you need to wait for that to complete. Worst case for me was filling a class 4 micro SD with > 32GB of music. My machine has 16GB of RAM, and a quite fast HDD, so it soon had a few GB queued, which drains at > about 1MB/sec (due to some issues on the other end of the USB, with a similar root cause). if you are right this is simply a dumb behavior since on a machone with a quad-core CPU with HT and 16 GB memory there has NOTHING to wait and destroy optimizings for VMware/RAID10 using every day to get les freezes in the UI is not a solution on a TTY there is no hang, no impact and so there goes something TERRIBLE wrong what should be fixed somehow
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ kde mailing list kde@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
