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

On Wed, Jun 25, 2008 at 10:45, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> I'm guessing you mean one integer per semaphore, which would actually use
> quite a bit of precious non-pageable kernel memory.

Unless I overlooked something (I did the math by hand),
sizeof(sem_entry) is 36 bytes (which makes the math in
/src/system/kernel/sem.cpp, line 311, wrong). Adding an extra int32
makes it 40 bytes long, and would make the semaphore table 5MB big on
a 1GB machine, instead of the current 4.5MB. I don't think it's that
criminally wrong...

> From BeOS experience this works rather well, actually.

Come on :) It took a *lot* of time and hard work from the BeZilla team
to make Firefox reasonably responsive under BeOS. Maddest props to
Sergei and team, by the way! But we just can't assume every piece of
ported software will receive the same level of dedication, specially
in the case of software that uses portable toolkits like Qt and GTK.

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

Quite true, but how about software that's born on a platform where
priority levels are traditionally not messed with and whose kernel has
lots of special-casing so that such software runs with any level of
decent responsiveness, thus relieving the programmer from taking
greater care in setting priorities? I won't have to resort to the
"*cough* Linux *cough*" kind of jokes, will I? ;)

> That there will be responsiveness issues is pure speculation on your part.
> You're trying to cure a problem that might not even exist.

Not cure; prevent. ;)

> How about first
> leaving that out and later *if* there turn out to be responsiveness problem
> (or potential for optimization) tackle those?

As I said on the previous message, it's a fundamental issue of fair
schedulers. Either interactive threads get boosted because they didn't
consume a full quantum, or they must get boosted by other means. Kiss
a short and easy to understand scheduler goodbye if you choose the
first route...

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

It's not an *optimization*, it's a *method* of boosting. And it would
not make it superfluous, only more relevant in the context of the
application itself rather than the OS as a whole, since threads that
actually go through a given code path will get boosted according to
the code path followed, and not just per the programmer's discretion.

> Sorry, not at all.

Eh. ;)


Cheers,
A.

Other related posts: