[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Tue, 08 Nov 2011 17:05:09 -0000
#8007: [app_server] fully unresponsive when resizing window of big textfile
-----------------------------+----------------------------
Reporter: ttcoder | Owner: axeld
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: System/Kernel | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
-----------------------------+----------------------------
Comment (by bonefish):
Replying to [comment:24 axeld]:
> I would implement an easier approach at first, and see if that already
serves us good enough, namely just boosting the next quantum of that
thread. But you've probably removed the thread::next_priority field
already in the mean time, I guess? That would make this change really
simple.
`Thread::next_priority` is still there. Since it is only used (and
immediately reset) in `enqueue_in_run_queue()` that implementation might
not be that simple either.
> Implementing the real thing unfortunately also makes mutexes a bit more
expensive.
Memory-wise it should be three pointers (list link and thread pointer)
plus maybe a priority field and minus the counter field. Performance-wise
it shouldn't affect uncontended locks at all. It should still be possible
to implement `mutex_{lock,unlock}()` for a mutex that isn't locked
respectively on which no other thread is waiting inline as an atomic
operation. Only the less likely operations will become more complex.
I have to amend what I wrote in my previous comment: There's no need to
maintain a list of all locks a thread holds. It is sufficient to include
only the locks that other threads are waiting on. That also relieves us
from reviewing all code that currently uses the locks we would change with
respect to explicit lock destruction, since a lock a thread is still
waiting on mustn't be destroyed anyway.
Replying to [comment:25 SeanCollins]:
> @bonefish
>
> I do not have any changes made to the kernel debug levels. I can reduce
those settings and retest to see if the build time is dramatically
effected ?? Thank you for the explanation
It's a compile time option. Have a look at the `build/config_headers`
directory, particularly the `ReadMe` and `kernel_debug_config.h` (the
`KDEBUG_LEVEL` definition). I probably wouldn't call the effect on the
build time dramatic, but it's definitely significant. The effect on the
kernel time alone is even more significant.
--
Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:26>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
