[haiku-development] Re: The new locking primitives and boosting -- I need some guidance here :)
- From: "Rene Gollent" <anevilyak@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 25 Jun 2008 16:49:37 -0500
On Wed, Jun 25, 2008 at 4:41 PM, André Braga <meianoite@xxxxxxxxx> wrote:
> 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...
I believe it's already 40 bytes due to structure padding.
> 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.
And that has a considerable amount to do with mozilla/firefox's
architecture in general, thread priorities is the bottom of the barrel
when it comes to the hurdles needed to make firefox run well.
>
>> 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? ;)
>
Except that in practice, responsiveness on Linux tends to suck in my
experience, so obviously that approach isn't working so well. Imo
priority inheritance is probably the better approach anyways, since
this also lends itself well to dealing with things like priority
inversion deadlocks and such.
Regards,
Rene
Other related posts:
