On Thu, Dec 4, 2008 at 10:45 AM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote: > Bruno Albuquerque <bga@xxxxxxxxxxxxx> wrote: >> Axel Dörfler wrote: >> > The "Haiku stands still with disk usage" is pretty much rendering >> > the >> > Eee unusable under Haiku, though, maybe we should start looking >> > into >> > this one day ;) >> BTW, what I find really weird is that even non disk-related stuff >> seems >> to slow to a crawl (or even completely stops) with heady disk IO. For >> example the app_server itself seems to hang and then return to life >> after disk IO subsides. > > That can have a number of reasons that need to be investigated: > Either there the I/O is caused by a thread that holds an important lock > - this might not always be that obvious, like string rendering. The > other option would be that the threads running have a very high > priority and don't let anyone else go. > Of course, it might also be a combination of this. We need to make sure > that disk access only happens on code paths that don't lock out the > app_server if possible; having the whole display lock isn't really that > nice an experience. Could some of it be related to disk activity as a result of swapfile support now somehow being induced by memory-allocation activities?