From: "Krzysztof Helt" <krzysztof.h1@wp.pl>
To: sparclinux@vger.kernel.org
Subject: Re: 2.6.17-rc5 does not build for sparc
Date: Thu, 08 Jun 2006 11:33:20 +0000 [thread overview]
Message-ID: <44880b0026284@wp.pl> (raw)
In-Reply-To: <4478bffd45960@wp.pl>
My two cents to this discussion.
I consider both of these macros (write_can_lock and
read_can_lock) brain-damaged as they do not guarantee anything.
That's why I haven't copied the read_can_lock macro - it is not
used in the sparc kernel and let it be this way.
The write_can_lock is used in one place only - in ptrace.c file
when it is used to add a little efficiency into a waiting for two
spinlocks to be free. I suppose this call can be removed but I
afraid changing it. A whole idea there is simple: obtain one
lock, try to obtain another one and if it is not successful use
the write_can_lock macro to wait before repeating former steps. I
think that without this macro the waiting may become less
efficient - more trials of obtaining lock will be made. See the
code below:
repeat:
/*
* Nasty, nasty.
*
* We want to hold both the task-lock and the
* tasklist_lock for writing at the same time.
* But that's against the rules (tasklist_lock
* is taken for reading by interrupts on other
* cpu's that may have task_lock).
*/
task_lock(task);
local_irq_disable();
if (!write_trylock(&tasklist_lock)) {
local_irq_enable();
task_unlock(task);
do {
cpu_relax();
} while (!write_can_lock(&tasklist_lock));
goto repeat;
}
There is no need for this macro to be 100% accurate. It is enough
to be conservative as Bob Breuer suggested (it should not spin
waiting either). The other way is to remove the call to
write_can_lock from the code above.
I beg you (sparc32 maintainers) to start pushing smp patches (or
even parts of them) into the kernel tree. I have another patch
which clears sun4m_smp.c a little (replaced loops with
for_each_online_cpu, removed one unused global variable) but this
will stop Bob Breuer's patch from applying so I wait sitting on it.
I am able to boot a dual SM81 in SS20 with all the smp patches
from this list, but the kernel hangs on first module load. It is
something I will investigate.
Regards,
Krzysztof
----------------------------------------------------
Nowe serie superksi±¿ek o Czarodziejkach WITCH!
Poznaj ¶wiat bohaterek WITCH!
Will, Irma, Taranee, Cornelia i Hay-Lin zapraszaj± do ksiêgarni.
http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fwitch.html&sidx1
prev parent reply other threads:[~2006-06-08 11:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-27 21:09 2.6.17-rc5 does not build for sparc Krzysztof Helt
2006-05-27 22:43 ` Bob Breuer
2006-05-28 9:30 ` BERTRAND Joël
2006-05-28 10:27 ` Christian Joensson
2006-05-29 6:03 ` Krzysztof Helt
2006-06-06 4:15 ` David Miller
2006-06-06 4:59 ` Bob Breuer
2006-06-06 5:08 ` David Miller
2006-06-06 7:09 ` Bob Breuer
2006-06-08 11:33 ` Krzysztof Helt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44880b0026284@wp.pl \
--to=krzysztof.h1@wp.pl \
--cc=sparclinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.