Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Jul 2010 19:12:27 +0200
From:      Gabor Kovesdan <gabor@FreeBSD.org>
To:        soc-status@freebsd.org
Cc:        =?UTF-8?B?RWR3YXJkIFRvbWFzeiBOYXBpZXJhxYJh?= <trasz@FreeBSD.org>
Subject:   Collective resource limits status report #6
Message-ID:  <4C39FB7B.4030203@FreeBSD.org>
In-Reply-To: <4C30B90F.9040703@FreeBSD.org>
References:  <4C1BCB96.4040608@FreeBSD.org>	<AANLkTikwUYWCIvlDQ60L4L8gMcEeDFIV6850csEwuH8E@mail.gmail.com>	<4C21CAF0.2040607@FreeBSD.org>	<AANLkTikLoskpABjaUlufnBGOBeU-Z62CiuQfH5sDyY1Z@mail.gmail.com>	<4C230A0B.3080700@FreeBSD.org>	<4C2761B8.9030800@FreeBSD.org> <4C30B90F.9040703@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Since last report, I've found out where's the bug in my code I just 
don't know yet the reason and the solution. The upper half of a 64-bit 
variable gets corrupted and then a comparison, which should evaluate to 
true just fails. I'll switch to a 32-bit jid_t for now and hopefully 
that will solve this and I can progress until I find out the reason and 
then I can switch back to a 64-bit jid_t.

Apart from this investigation, I've cleanup up the locking. First, I 
wanted to add a 2-level locking, one lock for the linked list itself 
that holds the job entries and one particular lock for each entry. I 
wanted to minimize sleeping on locks in this way but probably it was an 
overkill because these operations are short and the locking overhead 
might be higher than what we could gain. And it just didn't work 
correctly. Now I only use one rwlock for list operations and it seems fine.

I've also added some lines of code and applied some whitespace cleanup. 
Now buildworld/buildkernel is running and when it finishes I hope my 
code will work with 32-bit jid_t and then finally I can concentrate on 
actual limits.

Latest sources in //depot/projects/soc2010/gabor_jobs/irix_jobs/.

Gabor



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C39FB7B.4030203>