[haiku-development] Re: Latest changes and general status.

On 2008-04-23 at 04:08:35 [+0200], Bruno Albuquerque <bga@xxxxxxxxxxxxx> 
wrote:
> Ingo Weinhold escreveu:
> >> Then recently Ingo found and tracked down a bug where our semaphore code
> >> was not really working as expected and ended up doing what seems to be a
> >> complete rewrite of our locking primitives. Well, giving credit where
> >> credit is due, this was probably, at least on my configuration, the 
> >> single
> >> change in Haiku with the most impact since we actually managed to run
> >> Tracker on it. Not only Haiku feels a lot faster now (compiling it inside
> >> itself seems to be at least one order of magnitude faster) as the last 
> >> bug
> >> I was still getting (a random mimeset failure while building) is now 
> >> gone.
> >> I managed, again, to build Haiku (up to a point, see below) inside 
> >> itself!
> > 
> > Really? 8-O
> > Thanks for the praise, but I'm utterly surprised, that my changes would
> > have any such impact. The semaphore bug should only have been triggered in
> > very rare circumstances -- which is probably why it hadn't been discovered
> > before (I only saw it when reading the code). Regarding the restructuring
> > of the locking primitives, that shouldn't have any noticible performance
> > impact yet. Well, our snooze() performs better now. :-P And since a few
> > hours also blocking reads from pipes.
> 
> Maybe it has, for some reason, a bigger impact in a my configuration
> (which is now a Intel Core 2 Extreme with 4 cores at 3.83 GHz and 12 Mb
> of L2 cache)?

4 cores, nice. :-)

> The difference *IS* impressive. Before these changes
> compiling under Haiku was similar to compiling under ZETA (to be fair,
> it was faster under Haiku but not, say, 2 times faster) and now it is
> similar to compiling under Linux (although, as expected, Linux is still
> faster).

Well, I won't complain, I just have no clue, why. :-) BTW, do you build with 
-j4 or something?

> In any case, you did manage to fix the random mimeset error I
> usually got (General OS Error) and that is good enough for me. :)

This one puzzles me even more. :-)

> Anyway, take a look at bug #2142 as this is where it is stopping now (I
> compiled Haiku 4 times in a row just to be sure and it stopped at the
> same point all the time).

Yep, that's a dup of #1991 and the reason is well understood: Jam thinks our 
command line limit is 40KB, but it is only 16KB ATM. Hence it can produce 
command lines that get truncated and thus fail. Our bash might have an even 
stricter limit.

You could try to build a jam with 16 KB limit (can be set in jam.h), but then 
the build will probably fail nevertheless, since we might indeed have rules 
that require longer lines. We'll have to adjust that limit in the kernel and 
maybe find a better way to deal with the parameters. The syscalls for exec*() 
and load_image() could for instance already provide a flattened 
representation of the buffer, so that the kernel has less work copying it.

> > [...]
> >> 2 - I started to get some new KDLs in the block cache after Ingo's
> >> changes. It seems to be easy to reproduce when trying to start firefox
> >> after compiling Haiku inside itself. I will also create a bug about this.
> > 
> > I wouldn't rule out that my changes are to blame, but there's already
> > #2059, which predates them. Incidently I've just ran into the same bug and
> > am trying to analyze it ATM. I haven't come very far yet, though. I've 
> > only
> > understood that the block cache's pending_notification list has somehow
> > become corrupt (the notification's next link has an invalid value which
> > causes the crash when removing it from the list).
> 
> I got another one in net timer. Check bug #2143. I am pretty sure this
> is related to your recent changes as, if I am not mistaken, you did
> change how timers work.

That's only indirectly related. The net stack timer thread uses a semaphore 
for timing out. The problem could, of course, still be related to my changes, 
but I wouldn't be so sure.

CU, Ingo

Other related posts: