[haiku-development] Re: The new locking primitives and boosting -- I need some guidance here :)

On 2008-06-25 at 07:03:46 [+0200], André Braga <meianoite@xxxxxxxxx> wrote:
> On Wed, Jun 25, 2008 at 00:37, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
[...]
> > Well, it adds overhead.
> 
> If my proposal is as effective as I believe it is, I'm willing to live
> with the overhead of a single integer, a conditional test, a sum and
> an assignment. ;)

I'm guessing you mean one integer per semaphore, which would actually use 
quite a bit of precious non-pageable kernel memory.

> > The main question is whether this kind of
> > optimization is necessary at all. As François already mentioned threads
> > that need very low latencies (and don't do much work) just get a high
> > priority. Analogously worker threads should be given priorities lower than
> > B_NORMAL_PRIORITY. IMHO when these simple rules are respected a relatively
> > fair scheduler would automatically schedule threads in such a way that the
> > interactive user experience is just fine.
> 
> Well, the key here is exactly what you just brought: would everybody
> play by the rules all the time? Would ported software play by our
> rules? Would software by newcoming developers play by our rules? Would
> software that depend mostly on interpreted languages (Java, Python,
> Lua, Ruby, you name it) play by our rules? I don't quite think so.

From BeOS experience this works rather well, actually.

> If going my route buys us *nothing* but a better experience when
> running ported software where upstream won't accept patches with
> Haiku-specific tweaks to their threading code I'd consider my mission
> thoroughly accomplished:

Ports of software with GUI contain by definition quite a bit of platform 
specific code. I doubt that setting thread priorities is a big problem.

> Java, Firefox, Webkit, OpenOffice, AbiWord,
> GNU tools, countless games; those are all ported software after all.
> Until we manage to convince them to tune their software to Haiku

There's actually little to tune. That it's not a good idea to run worker 
threads with high priority is universally true.

> there's no reason we should settle for having responsiveness issues
> when running said software,

That there will be responsiveness issues is pure speculation on your part. 
You're trying to cure a problem that might not even exist. How about first 
leaving that out and later *if* there turn out to be responsiveness problem 
(or potential for optimization) tackle those?

> and if a smart scheduler makes this point
> kind of mute it would actually encourage people to port their software
> over to Haiku. And make the job of writing native software even
> easier. The best code is code that doesn't have to be written at all,
> isn't it? How about not having to write a call to
> suggest_thread_priority? ;)

I'm not sure why you think your suggested optimization would make setting an 
appropriate thread priority superfluous.

[...]
> > To be honest, I'm very sceptical whether this kind of optimization is
> > really useful.
> 
> Did I manage to convince you? ;)

Sorry, not at all.

CU, Ingo

Other related posts: