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>