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

On 2008-06-25 at 23:41:06 [+0200], 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...

Yep, 0.5 MB should be right. That doesn't sound a lot, but then again, it's 
physical memory that is lost to the system.

> > 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.

I don't have any insights into what kind of optimizations were done in the 
Firefox port, but I doubt that much of it had to do with fine-tuning thread 
priorities. At least to me it looks like all threads just have their default 
priority (B_DISPLAY_PRIORITY for windows, B_NORMAL_PRIORITY for others).

> > 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? ;)

Again, that's all just speculation.

> > 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. ;)

Fine, then you're trying to prevent 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?
> 
> 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 pretty ignorant with respect to scheduler implementations, but the first 
option sounds exactly like what the scheduler should do. If a similar 
behavior can be achieved by other, easier means, fine by me. Alas I don't 
think semaphore branding does that. For one, if I understand it correctly, a 
thread that used 99% of its quantum before starting to wait on a low-latency 
branded semaphore will be boosted in just the same way a thread that used 
only 1% would. Furthermore I'm afraid you just can't brand most of the 
locking primitives a thread runs through, since most of them are shared by 
different threads with different purposes (and thus different priorities).

> > 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.

A change of/addition to an algorithm to improve responsiveness would fit my 
definition of optimization, but feel free to call it by any name you like. :-)

> 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.

As said before (and as I tried to explain by the example in my previous mail) 
most locking primitives can't be branded. And those that you can brand don't 
really add value. Like the receive end of a BWindow port -- it is only used 
by the window thread, which per default has display priority.

CU, Ingo

Other related posts: